www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Overloading based on attributes - is it a good idea?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
int fun(int) pure;
int fun(int);

pure int gun(int x)
{
    return fun(x);
}

This doesn't work, but on the face of it it's not ambiguous - the second 
overload of fun() would not compile anyway.

I was wondering whether allowing overloading on attributes in general 
would be a good idea. I suspect templates and attribute deduction make 
that difficult.
May 28
next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 28 May 2019 at 16:08:38 UTC, Andrei Alexandrescu 
wrote:
 int fun(int) pure;
 int fun(int);

 pure int gun(int x)
 {
    return fun(x);
 }

 This doesn't work, but on the face of it it's not ambiguous - 
 the second overload of fun() would not compile anyway.

 I was wondering whether allowing overloading on attributes in 
 general would be a good idea. I suspect templates and attribute 
 deduction make that difficult.
I posed this question a few years ago but specifically for nogc. Maybe it makes sense for some attributes but not for others? I think there could be some good use cases for overloading on nogc, which would allow you to choose a different implementation depending on whether the GC is being used or not.
May 28
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2019 9:08 AM, Andrei Alexandrescu wrote:
 int fun(int) pure;
 int fun(int);
 
 pure int gun(int x)
 {
     return fun(x);
 }
 
 This doesn't work, but on the face of it it's not ambiguous - the second 
 overload of fun() would not compile anyway.
 
 I was wondering whether allowing overloading on attributes in general would be
a 
 good idea. I suspect templates and attribute deduction make that difficult.
More than difficult. I suspect it's impossible in the general case. D does inference of types and attributes from the bottom up, but this would be bottom up and top down. It's easy to know what to do for trivial cases, but for multiple levels and choices, that's graph theory that would be very complex to find a unique solution, and if a unique solution cannot be found, imagine the problems with informing the user just why. It's like overloading based on return value: long fun(int); int fun(int); int gun(int x) { return fun(x); } It's ambiguous even though the first overload of fun() would give an error. Another consideration: class A { int fun() pure; } class B : A { overload int fun(); } Because of covariance/contravariance, B.fun doesn't need to have the pure attribute added, the pureness is inherited from A.fun.
May 28
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 28 May 2019 at 17:27:08 UTC, Walter Bright wrote:
 On 5/28/2019 9:08 AM, Andrei Alexandrescu wrote:
 int fun(int) pure;
 int fun(int);
 
 pure int gun(int x)
 {
     return fun(x);
 }
 
 This doesn't work, but on the face of it it's not ambiguous - 
 the second overload of fun() would not compile anyway.
 
 I was wondering whether allowing overloading on attributes in 
 general would be a good idea. I suspect templates and 
 attribute deduction make that difficult.
More than difficult. I suspect it's impossible in the general case. D does inference of types and attributes from the bottom up, but this would be bottom up and top down. It's easy to know what to do for trivial cases, but for multiple levels and choices, that's graph theory that would be very complex to find a unique solution, and if a unique solution cannot be found, imagine the problems with informing the user just why. It's like overloading based on return value: long fun(int); int fun(int); int gun(int x) { return fun(x); } It's ambiguous even though the first overload of fun() would give an error. Another consideration: class A { int fun() pure; } class B : A { overload int fun(); } Because of covariance/contravariance, B.fun doesn't need to have the pure attribute added, the pureness is inherited from A.fun.
At first glance this does seem correct. After reading Walter's response here, another thought came to mind that instead of attribute overloading, a template with static-if could also be used. void foo()() { static if (__traits(gcAllowedHere)) { // the GC implementation } else { // the nogc implementation } } void bar1() nogc { foo(); // calls the nogc implementation } void bar2() { foo(); // calls the GC implementation } And the same thing could be applied for purity with something like __traits(inpureAllowedHere). Although, I think we could use existing traits for these, with an "isCompiles" or something.
May 28
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2019 10:35 AM, Jonathan Marler wrote:
 After reading Walter's response here, another thought came to mind that
instead 
 of attribute overloading, a template with static-if could also be used.
nogc attributes are often inferred. Such constructs would make it undecidable.
May 28
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 28 May 2019 at 18:07:47 UTC, Walter Bright wrote:
 On 5/28/2019 10:35 AM, Jonathan Marler wrote:
 After reading Walter's response here, another thought came to 
 mind that instead of attribute overloading, a template with 
 static-if could also be used.
nogc attributes are often inferred. Such constructs would make it undecidable.
You're right it's undecidable inside the function, but I think it's decidable if you check it at the call site. So if we could pass that information to the template then we could use it. Using a default template parameter could work, though, we'd likely need to modify __traits(compiles) to work in the callers context when used as a default template parameter, or create a new trait like __trait(compilesAtCallSite): int main(string[] args) { nogcExample(); gcExample(); return 0; } version (WorksToday) { void nogcExample() nogc { allocateString!(__traits(compiles, new Object))(100); } void gcExample() { allocateString!(__traits(compiles, new Object))(100); } auto allocateString(bool allowGC)(size_t size) { static if (allowGC) { return new char[size]; } else { import core.stdc.stdlib : malloc; return (cast(char*)malloc(size))[0 .. size]; } } } else version (UseCompilesAtCallSite) { void nogcExample() nogc { allocateString(100); } void gcExample() { allocateString(100); } auto allocateString(bool allowGC = __traits(compilesAtCallSite, new Object))(size_t size) { static if (allowGC) { return new char[size]; } else { import core.stdc.stdlib : malloc; return (cast(char*)malloc(size))[0 .. size]; } } } Then again maybe if the nogcExample/gcExample functions were also templates, then we wouldn't be able to infer whether or not gc was available...not sure on that one.
May 28
next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 28 May 2019 at 19:49:40 UTC, Jonathan Marler wrote:
 On Tuesday, 28 May 2019 at 18:07:47 UTC, Walter Bright wrote:
 On 5/28/2019 10:35 AM, Jonathan Marler wrote:
 After reading Walter's response here, another thought came to 
 mind that instead of attribute overloading, a template with 
 static-if could also be used.
nogc attributes are often inferred. Such constructs would make it undecidable.
You're right it's undecidable inside the function, but I think it's decidable if you check it at the call site. So if we could pass that information to the template then we could use it. Using a default template parameter could work, though, we'd likely need to modify __traits(compiles) to work in the callers context when used as a default template parameter, or create a new trait like __trait(compilesAtCallSite): int main(string[] args) { nogcExample(); gcExample(); return 0; } version (WorksToday) { void nogcExample() nogc { allocateString!(__traits(compiles, new Object))(100); } void gcExample() { allocateString!(__traits(compiles, new Object))(100); } auto allocateString(bool allowGC)(size_t size) { static if (allowGC) { return new char[size]; } else { import core.stdc.stdlib : malloc; return (cast(char*)malloc(size))[0 .. size]; } } } else version (UseCompilesAtCallSite) { void nogcExample() nogc { allocateString(100); } void gcExample() { allocateString(100); } auto allocateString(bool allowGC = __traits(compilesAtCallSite, new Object))(size_t size) { static if (allowGC) { return new char[size]; } else { import core.stdc.stdlib : malloc; return (cast(char*)malloc(size))[0 .. size]; } } } Then again maybe if the nogcExample/gcExample functions were also templates, then we wouldn't be able to infer whether or not gc was available...not sure on that one.
Another thought. If you wanted to propagate this "allowGC" information, you would probably have to explicitly pass it down each template. For example, if the "nogcExample" and "gcExample" functions were also templates that could optionally use GC, then they would have to explicitly pass that information to the "allocateString template". If that's the case then this doesn't scale. It looks like if you implement this solution fully, the template parameters become analogous to function attributes. So maybe for specific attributes, allowing them to be overloaded might the right way to go. Of course, this brings us back to Andrei's original question which is whether or not allowing attributes to be overloaded would be worth the trouble to support.
May 28
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2019 12:49 PM, Jonathan Marler wrote:
 You're right it's undecidable inside the function, but I think it's decidable
if 
 you check it at the call site.
Yet the call site may also be doing attribute inference. Think of a graph with nodes in it, all interconnected with arbitrary edges, including cycles, and you have to find a set of attributes that satisfy each of the edges in it, when adding any attribute changes the topology of the graph. Even if there is an algorithm which can solve this, and I don't have a PhD in graph theory and have no idea if there is one or not: 1. there may be N solutions - which one is picked? 2. how do you explain to the user why? 3. how do you explain to the user when N is zero? 4. the combinatorics of this may mean it takes essentially infinite time 5. I have a hard enough time implementing/debugging the current bottom-up method 6. I've spent years dealing with problems with forward references, when there are cycles in the reference graph and incomplete types. Your proposal makes that infinitely worse. Like I said, it looks workable for trivial boundary cases, but that isn't how things work when people start using such a feature. So, no. Hell no :-)
May 28
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 28 May 2019 at 20:26:50 UTC, Walter Bright wrote:
 On 5/28/2019 12:49 PM, Jonathan Marler wrote:
 You're right it's undecidable inside the function, but I think 
 it's decidable if you check it at the call site.
Yet the call site may also be doing attribute inference. Think of a graph with nodes in it, all interconnected with arbitrary edges, including cycles, and you have to find a set of attributes that satisfy each of the edges in it, when adding any attribute changes the topology of the graph. Even if there is an algorithm which can solve this, and I don't have a PhD in graph theory and have no idea if there is one or not: 1. there may be N solutions - which one is picked? 2. how do you explain to the user why? 3. how do you explain to the user when N is zero? 4. the combinatorics of this may mean it takes essentially infinite time 5. I have a hard enough time implementing/debugging the current bottom-up method 6. I've spent years dealing with problems with forward references, when there are cycles in the reference graph and incomplete types. Your proposal makes that infinitely worse. Like I said, it looks workable for trivial boundary cases, but that isn't how things work when people start using such a feature. So, no. Hell no :-)
Unfortunately my mathematical emphasis was on number theory and combinatorics...and it was only a bachelors :) But after sending my initial response I realized that if my example functions were also templates, then they would also have to use the allowGC = __traits(callSiteCompiles, new Object). In fact, in order to propogate the information, every template function that could eventually call one of these allowGC templates would also need to add the allowGC parameter to their template parameter list. Completely unscalable. That being said, even though the solution is unscalable and verbose, it does actually work. The compiler today is able to infer these attributes as demonstrated by the first version in my example code I showed earlier. And it will also work no matter how deep the rabit hole goes...turtles all the way down. It works because it determines the GC requirement top-down starting from the first non-template. Since non-templates do not infer the nogc attribute, the compiler already knows the answer to this inside each function that isn't a template. So we just need a way to propagate that information to each template instantiated inside that function which is what the template parameter allowGC did. We know this solution doesn't scale when using template parameters, but it would work if the compiler kept track of this internally. You'd just need to add a boolean variable to each template instance that indicates whether the caller allowed the GC or not, that is passed in when the template is instantiated. Anyway, I'm not saying we should do it, or even that we should do it this way, just saying it could be done. The math here is actually pretty simple, no need for a PhD this time.
May 28
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2019 2:12 PM, Jonathan Marler wrote:
 turtles all the way down.
Again, it is not that simple. Call graphs have cycles in them, they are not acyclic. Furthermore, since you suggested different code be instantiated based on inferred attributes, you have a FAR FAR more complex problem to resolve, since the graph connections change at every decision point.
May 28
next sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 28 May 2019 at 21:41:28 UTC, Walter Bright wrote:
 On 5/28/2019 2:12 PM, Jonathan Marler wrote:
 turtles all the way down.
Again, it is not that simple. Call graphs have cycles in them, they are not acyclic. Furthermore, since you suggested different code be instantiated based on inferred attributes, you have a FAR FAR more complex problem to resolve, since the graph connections change at every decision point.
Again, in this case it is that simple. I'll explain it another way, maybe it will make sense this time. Attributes on functions inside template are inferred bottom-up, but templates are instantiated top-down. So trying to use inferred attributes to affect template instances is going to get you into a cyclic mess. In this case you are absolutely right. What I was suggesting is that you propagate the state as to whether or not the GC is allowed top-down, the same way templates are instantiated. You could do this today with template parameters, but like I said, it's not scalable because it requires every single template to add this parameter. It works because you are propagating this state in the same direction as you are instantiating the templates, top down, so you know before you even see the inside of the template whether or not the GC is allowed. So the argument that this creates a complex cyclic dependency resolution problem is not correct in the example I showed. However, there are other arguments against it, the main one I see being that you would essentially need to add "implicit template parameters". This would be a big change to the language with alot of consequences, something that would most certainly require a DIP and alot of research and thought, but, you shouldn't immediately dismiss and idea with "Hell No", especially when you don't fully understand it.
May 28
prev sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 28 May 2019 at 21:41:28 UTC, Walter Bright wrote:
 On 5/28/2019 2:12 PM, Jonathan Marler wrote:
 turtles all the way down.
Again, it is not that simple. Call graphs have cycles in them, they are not acyclic. Furthermore, since you suggested different code be instantiated based on inferred attributes, you have a FAR FAR more complex problem to resolve, since the graph connections change at every decision point.
I read your response again and I think there's another piece you might be missing. You are correct that call graphs are not acyclic, however, the inference of attributes only applies to templated-functions, not regular functions. So we don't need to walk the entire graph to determine whether or not a template is allowed to use the GC, you only need to trace each template to it's nearest non-template function. Of course, this is just the theory, in practice it's just propagated as an implicit template parameter, a feature which is probably worth looking into and discussing on its own.
May 28
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/28/2019 3:12 PM, Jonathan Marler wrote:
 You are correct that call graphs are not acyclic, however, the inference of 
 attributes only applies to templated-functions, not regular functions.  So we 
 don't need to walk the entire graph to determine whether or not a template is 
 allowed to use the GC, you only need to trace each template to it's nearest 
 non-template function.
Your algorithm will have to work for the worst case, which is all template code. This is hardly unreasonable, as Phobos is nearly entirely templates, with cyclical expansions. Worse, it's not just attribute inference, you proposed different code paths for different attributes, meaning the graph changes, too. It's a combinatorial explosion.
May 28
next sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 29 May 2019 at 01:14:04 UTC, Walter Bright wrote:
 On 5/28/2019 3:12 PM, Jonathan Marler wrote:
 You are correct that call graphs are not acyclic, however, the 
 inference of attributes only applies to templated-functions, 
 not regular functions.  So we don't need to walk the entire 
 graph to determine whether or not a template is allowed to use 
 the GC, you only need to trace each template to it's nearest 
 non-template function.
Your algorithm will have to work for the worst case, which is all template code. This is hardly unreasonable, as Phobos is nearly entirely templates, with cyclical expansions. Worse, it's not just attribute inference, you proposed different code paths for different attributes, meaning the graph changes, too. It's a combinatorial explosion.
Well, I didn't propose an algorithm. I was just providing a visual aid to your graph analogy. My suggesion has nothing to do with attribute inference on templates. If it did then you are completely right that this would be a combinatorial explosion. The idea is actually pretty "dumb" at its core. What's the simplest way to pass this information to a template? Just add a template parameter. foo(bool nogc, bool nothrow, bool pure,...)() { // logic to do something different based on template parameters } Then we need a way infer these attributes when we aren't inside a template. You can do this today with things like: foo!(__traits(compiles, new Object), __traits(compiles, throw new Object), ...)(); This function call is long, but the point of it is that this same call will pass the correct information based on whether the surrounding scope is nogc and/or nothrow. It infers the attributes before instantiating the template and passes the results to it. But keep in mind, it is not inferring attributes for the template, it is only passing information about the caller to the template which it may or may not use. But I think everyone can immediately see the problem with this. We can't add these parameters to every single template, and then add these __traits to every single template instantiation. There would be more boiler-plate than actual code! So came the idea of "implicit template parameters". The idea would be that any template could access a set of implicit variables to customize behavior. And to prevent an exponential explosion of template instances, you would only consider implicit template parameters when they are used, i.e. template foo() { static if (__traits(requiresNothrow)) auto foo() nothrow { ... } else auto foo() { ... } } void bar1() { foo(); } void bar2() nothrow { foo(); } When the compiler sees the `requiresNoThrow` trait being used inside a template, it notes that it is using one of the known implicit template parameters, meaning that it will be instantiated differently when the implicit "requiresNothrow" template parameter changes, just like it would if it was a normal template parameter. So in this example, the two calls to foo in bar1 and bar2 actually instantiate 2 versions of foo, even though they have the same "explicit template arguments", they have different "implicit template arguments". To understand how this works, note that implicit and explicit template parameters work the same way. So it would function just as if you had done this: template foo(bool nothrow) { static if (nothrow) auto foo() nothrow { ... } else auto foo() { ... } } void bar1() { foo!(__traits(compiles, new Object))(); } void bar2() nothrow { foo!(__traits(compiles, new Object))(); } It's just that now you don't need the boilerplate. Is it a good idea? I don't know, but I think it's worth some thought.
May 28
parent reply aliak <something something.com> writes:
On Wednesday, 29 May 2019 at 02:45:37 UTC, Jonathan Marler wrote:
 On Wednesday, 29 May 2019 at 01:14:04 UTC, Walter Bright wrote:
 [...]
Well, I didn't propose an algorithm. I was just providing a visual aid to your graph analogy. My suggesion has nothing to do with attribute inference on templates. If it did then you are completely right that this would be a combinatorial explosion. The idea is actually pretty "dumb" at its core. What's the simplest way to pass this information to a template? Just add a template parameter. [...]
Doesn't Jai do something similar to this? I.e. it passes in the "context" of the caller so that you can alter your code on what the environment is outside the function. So the context would could be a struct struct Conctext { bool isNogc; bool isSafe; // etc... } It's be akin to introducing the concept of a "compile time this" isn't it?
May 29
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 29 May 2019 at 12:39:16 UTC, aliak wrote:
 On Wednesday, 29 May 2019 at 02:45:37 UTC, Jonathan Marler 
 wrote:
 On Wednesday, 29 May 2019 at 01:14:04 UTC, Walter Bright wrote:
 [...]
Well, I didn't propose an algorithm. I was just providing a visual aid to your graph analogy. My suggesion has nothing to do with attribute inference on templates. If it did then you are completely right that this would be a combinatorial explosion. The idea is actually pretty "dumb" at its core. What's the simplest way to pass this information to a template? Just add a template parameter. [...]
Doesn't Jai do something similar to this? I.e. it passes in the "context" of the caller so that you can alter your code on what the environment is outside the function. So the context would could be a struct struct Conctext { bool isNogc; bool isSafe; // etc... } It's be akin to introducing the concept of a "compile time this" isn't it?
Yes, last time I heard Jai was using sort of an implicit runtime parameter. However, I'm far from convinced it's a good idea at runtime . With implicit template parameters, they would only affect the template if they were used, so you only pay for it if you are using it. Not so with implicit runtime parameters.
May 29
prev sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 29 May 2019 at 01:14:04 UTC, Walter Bright wrote:
 On 5/28/2019 3:12 PM, Jonathan Marler wrote:
 You are correct that call graphs are not acyclic, however, the 
 inference of attributes only applies to templated-functions, 
 not regular functions.  So we don't need to walk the entire 
 graph to determine whether or not a template is allowed to use 
 the GC, you only need to trace each template to it's nearest 
 non-template function.
Your algorithm will have to work for the worst case, which is all template code. This is hardly unreasonable, as Phobos is nearly entirely templates, with cyclical expansions. Worse, it's not just attribute inference, you proposed different code paths for different attributes, meaning the graph changes, too. It's a combinatorial explosion.
You do realize that all template code literally compiles to nothing right? A template isn't code, it's just a "template" that can be instantiated. If all you have is templates then there's nothing to instantiate them.
May 28
parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 29 May 2019 at 02:50:24 UTC, Jonathan Marler wrote:
 On Wednesday, 29 May 2019 at 01:14:04 UTC, Walter Bright wrote:
 On 5/28/2019 3:12 PM, Jonathan Marler wrote:
 [...]
Your algorithm will have to work for the worst case, which is all template code. This is hardly unreasonable, as Phobos is nearly entirely templates, with cyclical expansions. Worse, it's not just attribute inference, you proposed different code paths for different attributes, meaning the graph changes, too. It's a combinatorial explosion.
You do realize that all template code literally compiles to nothing right? A template isn't code, it's just a "template" that can be instantiated. If all you have is templates then there's nothing to instantiate them.
I'm pretty sure Walter knows how templates work given that he's implemented them twice.
May 29
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 29 May 2019 at 09:50:13 UTC, Atila Neves wrote:
 On Wednesday, 29 May 2019 at 02:50:24 UTC, Jonathan Marler 
 wrote:
 On Wednesday, 29 May 2019 at 01:14:04 UTC, Walter Bright wrote:
 [...]
You do realize that all template code literally compiles to nothing right? A template isn't code, it's just a "template" that can be instantiated. If all you have is templates then there's nothing to instantiate them.
I'm pretty sure Walter knows how templates work given that he's implemented them twice.
Yeah, no argument from me.
May 29
prev sibling parent reply aliak <something something.com> writes:
On Tuesday, 28 May 2019 at 20:26:50 UTC, Walter Bright wrote:
 On 5/28/2019 12:49 PM, Jonathan Marler wrote:
 You're right it's undecidable inside the function, but I think 
 it's decidable if you check it at the call site.
Yet the call site may also be doing attribute inference. Think of a graph with nodes in it, all interconnected with arbitrary edges, including cycles, and you have to find a set of attributes that satisfy each of the edges in it, when adding any attribute changes the topology of the graph. Even if there is an algorithm which can solve this, and I don't have a PhD in graph theory and have no idea if there is one or not:
http://dev.stephendiehl.com/fun/006_hindley_milner.html ? And the so called Algorithm W. I'm nowhere close to understanding how it seems to work though. Swift uses an altered version: https://github.com/apple/swift/blob/master/docs/TypeChecker.rst I assume the solver magic is in here: https://github.com/apple/swift/blob/master/lib/Sema/CSSolver.cpp Rust used to use it but changed: http://smallcultfollowing.com/babysteps/blog/2014/07/09/an-experimental-new-type-inference-scheme-for-rust/ Though rust treats functions with different return types as the same definition and gives you an error. The thing you said about overloading on return types made me go and check around a bit. I already knew that swift does this at least. So I guess it isn't ambiguous since it's been implemented. But maybe it has something to do with the type system implementation they use? Cheers, - Ali
 1. there may be N solutions - which one is picked?
 2. how do you explain to the user why?
 3. how do you explain to the user when N is zero?
 4. the combinatorics of this may mean it takes essentially 
 infinite time
 5. I have a hard enough time implementing/debugging the current 
 bottom-up method
 6. I've spent years dealing with problems with forward 
 references, when there are cycles in the reference graph and 
 incomplete types. Your proposal makes that infinitely worse.

 Like I said, it looks workable for trivial boundary cases, but 
 that isn't how things work when people start using such a 
 feature.

 So, no. Hell no :-)
May 28
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 28 May 2019 at 22:33:46 UTC, aliak wrote:
 The thing you said about overloading on return types made me go 
 and check around a bit. I already knew that swift does this at 
 least. So I guess it isn't ambiguous since it's been 
 implemented. But maybe it has something to do with the type 
 system implementation they use?
It is possible, but when you have implicit type conversion... then you need to set up some strict presedence rules? Overloading over inferred attributes can be solved by a SAT solver, AFAIK, but that would require very good heuristics to perform well. The problem is most likely not in that complexity class, but simpler. Anyway, a solver can for each function find an expression for whether it is nogc or gc based on the ct parameters, so it is decidable. Same for nothrow.
May 28
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On Tue, May 28, 2019 at 11:10 AM Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 5/28/2019 10:35 AM, Jonathan Marler wrote:
 After reading Walter's response here, another thought came to mind that instead
 of attribute overloading, a template with static-if could also be used.
nogc attributes are often inferred. Such constructs would make it undecidable.
I have never encountered a case with nogc where I would want to overload on attribute alone; the function signature is never the same between a nogc and uses-gc function.
May 28
prev sibling parent KnightMare <black80 bk.ru> writes:
  nogc attributes are often inferred. Such constructs would make 
 it undecidable.
I doubt if nogc is needed to D. - it takes resources attempts to rewrite phobos/compiler for two different worlds. - we have good alternatives for that case: C++, rust, Go, Swift, ObjC.. - u can create almost same (x)strings, same int[]|double[]|real[], same maps/assoc.arrays with simple types(that (are|contains) no refs) through refcount. even slices can be rewritten that do addref/release for refs-containers - slice { ptrToContainer, index, length }. code can be same in text representation but incompatible at binary/obj - u cannot mix slices that point to GC-heap and using addref. BUT when include types with refs fields, when u have MOAO, when field can be Object obj.. well, compatibility is finish here - u should use refcount with cycling-breaker, u should use weakptr. it will be not D, it will be Swift/ObjC with "D"-frontend that need another separate RT lets say DiNoGC. why u want to do from D another Swift or C++ or rust? coz 0.1% lovers of bare metal want D for bare metal? but programmers for bare metal are 0.1% from all programmers and we have 0.0001%. we have totally 20kg of one programmer from 15k D-programmers (I threw dice) for whom u working, others use c++/rust/go. u can continue improve D/C++ Calypso https://github.com/Syniurge/Calypso remove GC from it and .. and u'll get strange C++ that knows 2 persons only. I can understand such job if no alternatives, somebody should be first, but we have alternatives with full RT already which grew up decades with a multimillion community for each alternative. D is good and unlike to others coz it have GC and it very close to metal(can do sse/assembler with high order functions) in one bottle (lets leave metaprogramming, UFCS, CTFE for ads slogans). u can say "without GC we can run D for WASM, for some hardware/arduino/raspberry". GC will appear in WASM. do u have RT for WASMwGC? ok, lets say another: how many people D-community will loose if will be declared "people, from today we finish works on nogc"? probably.. two men? D is good compiler, they cannot use strings, arrays, lambdas, well they can write own STL without GC. but they cannot use classes with polymorphism. with some allocator only. ok, lets write such allocator that supports some refcount and weakptr and again need another slices(with 3 fields). what to do with lambdas? same allocator too! imo such an allocator is very similar to GC. omg, we did cycle/loop to best DiNoGC and we are back to complicated version of slises, arrays/strings and classes and.. GC! again fking GC! that named aw/some allocator. ohh, no!). well, 2 men that want D on raspberry, I tell u and u will be grateful to me, go now to C++/Swift/Go, no need to cherish wet dreams about DiNoGC, u will get better world there, not with some crutches named "C++ without classes/D with structs/strange SwifD" Hallelujah!
May 28
prev sibling next sibling parent user1234 <user1234 12.de> writes:
On Tuesday, 28 May 2019 at 16:08:38 UTC, Andrei Alexandrescu 
wrote:
 int fun(int) pure;
 int fun(int);

 pure int gun(int x)
 {
    return fun(x);
 }

 This doesn't work, but on the face of it it's not ambiguous - 
 the second overload of fun() would not compile anyway.

 I was wondering whether allowing overloading on attributes in 
 general would be a good idea. I suspect templates and attribute 
 deduction make that difficult.
I'm afraid of non-intuitive or unexpected selection of overloads. Example during debugging someone realizes that "oh i see, this one is used actually".
May 28
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Tue, May 28, 2019 at 9:10 AM Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 int fun(int) pure;
 int fun(int);

 pure int gun(int x)
 {
     return fun(x);
 }

 This doesn't work, but on the face of it it's not ambiguous - the second
 overload of fun() would not compile anyway.

 I was wondering whether allowing overloading on attributes in general
 would be a good idea. I suspect templates and attribute deduction make
 that difficult.
I have wanted to overload on nothrow-ness before.
May 28
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Tuesday, 28 May 2019 at 21:53:13 UTC, Manu wrote:
 On Tue, May 28, 2019 at 9:10 AM Andrei Alexandrescu via 
 Digitalmars-d <digitalmars-d puremagic.com> wrote:
 int fun(int) pure;
 int fun(int);

 pure int gun(int x)
 {
     return fun(x);
 }

 This doesn't work, but on the face of it it's not ambiguous - 
 the second overload of fun() would not compile anyway.

 I was wondering whether allowing overloading on attributes in 
 general would be a good idea. I suspect templates and 
 attribute deduction make that difficult.
I have wanted to overload on nothrow-ness before.
Yeah I could see some nice ways to select an implementation based on nothrow. struct CannotFail { bool failed() { return false; } } struct CanFail { bool _failed; bool failed() { return _failed; } } auto foo(bool mustBeNothrow)() { static if (mustBeNothrow) { // logic ... return CanFail(true); // or CanFail(false); } else { if (foo!true().failed) throw new Exception("an exception"); return CannotFail(); } } Now you can call foo from nothrow code or code that can throw. If the return value follows the same api in both cases, you can implement something like. if (foo.failed) { // do something // note: if this block can throw, then foo.failed will get reduced to "false" // so this whole block should be removed }
May 28
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 28 May 2019 at 16:08:38 UTC, Andrei Alexandrescu 
wrote:
 int fun(int) pure;
 int fun(int);

 pure int gun(int x)
 {
    return fun(x);
 }

 This doesn't work, but on the face of it it's not ambiguous - 
 the second overload of fun() would not compile anyway.

 I was wondering whether allowing overloading on attributes in 
 general would be a good idea. I suspect templates and attribute 
 deduction make that difficult.
It worked between 2.075 and 2.085, called the pure overload.
May 29
parent Kagamin <spam here.lot> writes:
The fix was https://github.com/dlang/dmd/pull/9406
May 29
prev sibling next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 28 May 2019 at 16:08:38 UTC, Andrei Alexandrescu 
wrote:
 int fun(int) pure;
 int fun(int);

 pure int gun(int x)
 {
    return fun(x);
 }

 This doesn't work, but on the face of it it's not ambiguous - 
 the second overload of fun() would not compile anyway.

 I was wondering whether allowing overloading on attributes in 
 general would be a good idea. I suspect templates and attribute 
 deduction make that difficult.
That's a problematic idea. It means that adding an attribute on the caller can change the function that is called. Which seems exceedingly brittle. Arguing from a from a "principle of least surprise" standpoint. This is undesirable. - Stefan
May 29
prev sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Tuesday, 28 May 2019 at 16:08:38 UTC, Andrei Alexandrescu 
wrote:
 int fun(int) pure;
 int fun(int);

 pure int gun(int x)
 {
    return fun(x);
 }
I think it really depends on the attribute. I haven't thought too much about the other attributes, but for `pure` I don't see the use case. If you can make the implementation of `fun(int)` pure, why would you need an additional impure implementation? Mike
May 29
next sibling parent reply Manu <turkeyman gmail.com> writes:
On Wed, May 29, 2019 at 6:55 AM Mike Franklin via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 28 May 2019 at 16:08:38 UTC, Andrei Alexandrescu
 wrote:
 int fun(int) pure;
 int fun(int);

 pure int gun(int x)
 {
    return fun(x);
 }
I think it really depends on the attribute. I haven't thought too much about the other attributes, but for `pure` I don't see the use case. If you can make the implementation of `fun(int)` pure, why would you need an additional impure implementation?
Right. nothrow is the only one that makes any sense at all to me, I've thought that overloading on nothrow might be useful once or twice. Otherwise... pure; like you say, nogc; signature is always different anyway, safe; makes no sense...
May 29
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 30 May 2019 at 05:24:21 UTC, Manu wrote:
 Right. nothrow is the only one that makes any sense at all to 
 me, I've thought that overloading on nothrow might be useful 
 once or twice. Otherwise... pure; like you say,  nogc;
I wonder if overloading on nothrow could be better done as overloading on return value. Either you get "return value or exception" or you get "wrapped return value". What other use case is there?
May 30
parent reply Manu <turkeyman gmail.com> writes:
On Thu, May 30, 2019 at 12:55 AM Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Thursday, 30 May 2019 at 05:24:21 UTC, Manu wrote:
 Right. nothrow is the only one that makes any sense at all to
 me, I've thought that overloading on nothrow might be useful
 once or twice. Otherwise... pure; like you say,  nogc;
I wonder if overloading on nothrow could be better done as overloading on return value. Either you get "return value or exception" or you get "wrapped return value". What other use case is there?
out params. wrapping return values kinda sucks, inhibits RVO. overloading on return value seems problematic... how would that work?
May 31
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 31 May 2019 at 17:52:28 UTC, Manu wrote:
 out params. wrapping return values kinda sucks, inhibits RVO.
It can, yes. It requires more advanced RVO optimizations to avoid it.
 overloading on return value seems problematic... how would that 
 work?
The compiler narrows down possible return types until one is left. The simple version would require an explicit type, a more advanced version would look at how the result is used and use that to narrow down the candidate types until one is left.
May 31
parent reply Manu <turkeyman gmail.com> writes:
On Fri, May 31, 2019 at 11:35 AM Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Friday, 31 May 2019 at 17:52:28 UTC, Manu wrote:
 out params. wrapping return values kinda sucks, inhibits RVO.
It can, yes. It requires more advanced RVO optimizations to avoid it.
 overloading on return value seems problematic... how would that
 work?
The compiler narrows down possible return types until one is left. The simple version would require an explicit type, a more advanced version would look at how the result is used and use that to narrow down the candidate types until one is left.
A fun() { return A(); } B fun() { return B(); } fun(); // <- return value ignored ...?
May 31
next sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Friday, 31 May 2019 at 21:39:10 UTC, Manu wrote:
 On Fri, May 31, 2019 at 11:35 AM Ola Fosheim Grøstad via 
 Digitalmars-d <digitalmars-d puremagic.com> wrote:
 On Friday, 31 May 2019 at 17:52:28 UTC, Manu wrote:
 out params. wrapping return values kinda sucks, inhibits RVO.
It can, yes. It requires more advanced RVO optimizations to avoid it.
 overloading on return value seems problematic... how would 
 that work?
The compiler narrows down possible return types until one is left. The simple version would require an explicit type, a more advanced version would look at how the result is used and use that to narrow down the candidate types until one is left.
A fun() { return A(); } B fun() { return B(); } fun(); // <- return value ignored ...?
Ambiguous. cast(A)fun(); to call that specific overload. I guess that means cast(void)cast(A)fun(); if fun is pure... -- Simen
May 31
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 31 May 2019 at 21:39:10 UTC, Manu wrote:
 A fun() { return A(); }
 B fun() { return B(); }

 fun(); // <- return value ignored

 ...?
In this instance it is a matter of "ideological" language semantics. If the language "ideology" is spec-driven then compiler should be allowed to choose the one that does less work, given that they both are supposed to implement the same spec. The IDE can show which one is chosen, so I don't think it is as big a problem as people make it out to be (assuming you limit your imports). If the language has error-as-return-value as an idiom, then it might require the caller to check all returned errors. In that case it should pick the function call that throws if the caller does not use the returned value, and complain if both versions of "fun()" returns an error value. Anyway, you can get around it by: A _ = fun(); // _ is not used or: returns!A( fun() ); // wrapper that ensures the return type to be of A
May 31
prev sibling parent reply Exil <Exil gmall.com> writes:
On Thursday, 30 May 2019 at 05:24:21 UTC, Manu wrote:
 On Wed, May 29, 2019 at 6:55 AM Mike Franklin via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 On Tuesday, 28 May 2019 at 16:08:38 UTC, Andrei Alexandrescu 
 wrote:
 int fun(int) pure;
 int fun(int);

 pure int gun(int x)
 {
    return fun(x);
 }
I think it really depends on the attribute. I haven't thought too much about the other attributes, but for `pure` I don't see the use case. If you can make the implementation of `fun(int)` pure, why would you need an additional impure implementation?
Right. nothrow is the only one that makes any sense at all to me, I've thought that overloading on nothrow might be useful once or twice. Otherwise... pure; like you say, nogc; signature is always different anyway, safe; makes no sense...
I don't think it is that useful. Consider if you did do the following: void foo() nothrow; void foo(); void bar() nothrow { foo(); // ok useful calls foo() nothrow } void ree() { foo(); // ambiguous can call both, should be an error } It can call either function if the callee isn't nothrow. I don't think it should implicitly call the function without the nothrow either. It really varies on the situation which one should be called, you may want the variant that doesn't throw an exception. It would be surprising if you have a function defined as nothrow, then add an overload without the nothrow and now it is now calling a different overload in functions without nothrow. At which point this isn't all that useful, it will work as expected in nothrow functions but then you will have to explicitly choose which one to use otherwise. Which is basically the situation now with nothrow, you just have to use a different function name.
May 30
parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Thursday, 30 May 2019 at 13:58:20 UTC, Exil wrote:
 I don't think it is that useful. Consider if you did do the 
 following:

     void foo() nothrow;
     void foo();

     void bar() nothrow
     {
          foo(); // ok useful calls foo() nothrow
     }

     void ree()
     {
         foo(); // ambiguous can call both, should be an error
     }


 It can call either function if the callee isn't nothrow. I 
 don't think it should implicitly call the function without the 
 nothrow either. It really varies on the situation which one 
 should be called, you may want the variant that doesn't throw 
 an exception. It would be surprising if you have a function 
 defined as nothrow, then add an overload without the nothrow 
 and now it is now calling a different overload in functions 
 without nothrow. At which point this isn't all that useful, it 
 will work as expected in nothrow functions but then you will 
 have to explicitly choose which one to use otherwise. Which is 
 basically the situation now with nothrow, you just have to use 
 a different function name.
I think is is orthogonal to how `const` is used on non-static member functions: struct Example { void member() const { } void member() /*mutable*/ { } } Example ex; ex.member(); // calls mutable It could call either function if the callee is mutable. People all over the board think it should implicitly call the function without the const. It could vary on the situation which one should be called, but mostly, you may want the variant that uses mutability to its advantage. Nobody finds it surprising if you have a const method, then add a mutable overload and now it is now calling a different overload in functions where the object is mutable. You could handle mutable and const methods the same: Tell people they need different names. It just doesn't look so nice with operators (fixed names, you cannot choose another), type inference and meta-programming. Nobody sees a problem with that, and it's about the same thing: The context of the call decides which overload is chosen. It is nothing new, C++ does it since the beginning. As I see it, this is can be made into an argument for a `nothrow(some_ct_bool_value)` attribute.
May 30
parent reply Exil <Exil gmall.com> writes:
On Thursday, 30 May 2019 at 15:30:26 UTC, Q. Schroll wrote:
 On Thursday, 30 May 2019 at 13:58:20 UTC, Exil wrote:
 I don't think it is that useful. Consider if you did do the 
 following:

     void foo() nothrow;
     void foo();

     void bar() nothrow
     {
          foo(); // ok useful calls foo() nothrow
     }

     void ree()
     {
         foo(); // ambiguous can call both, should be an error
     }


 It can call either function if the callee isn't nothrow. I 
 don't think it should implicitly call the function without the 
 nothrow either. It really varies on the situation which one 
 should be called, you may want the variant that doesn't throw 
 an exception. It would be surprising if you have a function 
 defined as nothrow, then add an overload without the nothrow 
 and now it is now calling a different overload in functions 
 without nothrow. At which point this isn't all that useful, it 
 will work as expected in nothrow functions but then you will 
 have to explicitly choose which one to use otherwise. Which is 
 basically the situation now with nothrow, you just have to use 
 a different function name.
I think is is orthogonal to how `const` is used on non-static member functions: struct Example { void member() const { } void member() /*mutable*/ { } } Example ex; ex.member(); // calls mutable It could call either function if the callee is mutable. People all over the board think it should implicitly call the function without the const. It could vary on the situation which one should be called, but mostly, you may want the variant that uses mutability to its advantage. Nobody finds it surprising if you have a const method, then add a mutable overload and now it is now calling a different overload in functions where the object is mutable. You could handle mutable and const methods the same: Tell people they need different names. It just doesn't look so nice with operators (fixed names, you cannot choose another), type inference and meta-programming. Nobody sees a problem with that, and it's about the same thing: The context of the call decides which overload is chosen. It is nothing new, C++ does it since the beginning. As I see it, this is can be made into an argument for a `nothrow(some_ct_bool_value)` attribute.
It is not orthogonal at all. If you want to look at it this way. It looks like it is othrogonal to nothrow because of the syntactic sugar. What the actual definition is this: void member( ref const(Example) _this ); void member( ref Example _this ); It is part of the parameters, which is perfectly legal even as a static function not part of an object. Yes you can call either, but one is an exact type match and is chosen instead. Looking at nothrow now, it doesn't have any parameters that can be used to evaluate the function. void foo() nothrow; void foo(); In the case of const for an object, it is just syntactic sugar for an already existing feature that follows the rules for function selection. This proposed changed will be adding another layer to that, and it will be quite messy due to how templates auto infer their attributes. If you want to draw parallels with C++, you can't define a function as nothrow and non-nothrow in C++ (noexcept). It has to be defined as either one or the other.
May 31
parent reply Exil <Exil gmall.com> writes:
Found some odd behavior, seems if a template needs to reference 
itself, it does not add the  nogc attribute to itself. Meaning 
it's type is not  nogc/nothrow, but it can still be called in 
 nogc functions. Unless you take a pointer to it, then it doesn't 
have the attributes so it can't be called.

https://run.dlang.io/is/YJDs7y

import std.stdio;

void test3(t)() {
     import core.stdc.stdio;
     printf("%s\n", t.stringof.ptr);
}

void test2(bool check)()  {
     static if(check) test3!(typeof(&test2))();
     else              test3!(int)();
}

void main()  nogc {

     auto p1 = &test2!false;
     auto p2 = &test2!true;
	
     test2!false();
     p1();

     test2!true(); // ok
     // p2(); // error can't call  nogc function

     printf("---\n%s\n%s\n", typeof(p1).stringof.ptr, 
typeof(p2).stringof.ptr);
}
Jun 01
parent Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 1 June 2019 at 12:08:50 UTC, Exil wrote:
 Found some odd behavior, seems if a template needs to reference 
 itself, it does not add the  nogc attribute to itself. Meaning 
 it's type is not  nogc/nothrow, but it can still be called in 
  nogc functions. Unless you take a pointer to it, then it 
 doesn't have the attributes so it can't be called.

 [...]
I've made an issue here: https://issues.dlang.org/show_bug.cgi?id=19934
Jun 01
prev sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 29 May 2019 at 13:53:37 UTC, Mike Franklin wrote:
 On Tuesday, 28 May 2019 at 16:08:38 UTC, Andrei Alexandrescu 
 wrote:
 int fun(int) pure;
 int fun(int);

 pure int gun(int x)
 {
    return fun(x);
 }
I think it really depends on the attribute. I haven't thought too much about the other attributes, but for `pure` I don't see the use case. If you can make the implementation of `fun(int)` pure, why would you need an additional impure implementation?
A use case I found is that the pure overload can use GC to allocate memory for CTFE, while the impure overload can use a custom allocator for run time. The compiler always chose pure overload, so I gave up on purity altogether.
May 30