Re: How can overloads be distinguished on attributes alone?
On Monday, 31 July 2023 at 18:15:25 UTC, Jonathan M Davis wrote:
On Monday, July 31, 2023 4:55:44 AM MDT Quirin Schroll via
Digitalmars-d-learn wrote:
Apparently, functions can be overloaded solely distinguished by
attributes:
```d
void f(ref int x) pure { x = 1; }
void f(ref int x) { x = 2; static int s; ++s; }
```
I thought that, maybe, a `pure` context calls the `pure`
function and an impure context calls the impure function, but
no: Calling `f` leads to an ambiguity error in both contexts.
Even if that worked, what about inferred contexts, i.e.
templates? In simple cases, they could forward the contexts in
which they are called, but you can instantiate a template
without calling it.
What am I missing here?
As things stand, the context in which a function is called is
irrelevant. All that matters is the arguments.
And actually, allowing it would complicate any functions that
infer attributes, potentially in a way that wouldn't work. For
instance, if you have a templated function that's trying to
infer purity, which one should it call? If it calls the pure
one, it could be pure, but if it doesn't, it can't be. Either
way, because the context isn't yet pure or not, the context
can't be used to determine which should be called. Potentially,
the compiler could just choose the pure function in that case,
but the problem gets worse as you add more attributes.
I reasoned like this up about this point.
For instance, what happens when you have a function that's pure
but not @safe and one that's @safe but not pure?
```d
void f() pure {...}
void f() @safe {...}
```
Should the compiler favor calling the pure one or the @safe
one? And what if you then add something to the function that
isn't @safe? If it was calling the @safe version before, should
it switch to the pure one? And if the functions were @safe pure
and @system and not pure instead
```d
void f() @safe pure {...}
void f() @system {...}
```
then changing the @safety or purity of some of the other code
in the templated function could result in the loss of both
attributes. And the more attributes are involved, the more
complex the situation gets.
I didn’t even consider multiple attributes “in competition”.
At this point, it’s obvious that this can’t work.
In effect, we'd be making the attribute inference process have
to go in two directions instead of just going from the bottom
up, with the added complication that it would potentially need
to choose between sets of attributes when choosing which
function overload to call.
I tried assigning the address to a function pointer to
disambiguate which overload I want. Didn’t work.
It's not necessarily the case that we couldn't sort all of this
out and come up with a clean set of rules that allowed
functions that infer their attributes to call the correct
function, but it does get pretty complicated, and it comes with
the serious downside that there's no guarantee that the
overloads even do something similar to one another.
Actually, I do think it’s impossible to do the right thing. The
spec can only make guesses on what a programmer might want.
And when you consider that it's pretty easy for a change in one
part of the code to change which attributes are inferred in
another part of the code, you could easily end up having a
change in one part of your program resulting in drastically
different behavior in a seemingly unrelated part of your
program. And even worse, that change could be because of a
library update, making it that much less obvious which parts of
your program could suddenly change behavior due to a change in
attributes.
Before looking into this, I thought that maybe this was in fact
intended.
And I'm probably forgetting other issues that this would add to
the mix. So, while it may very well be possible to do something
along the lines of what you're looking for, I strongly suspect
that it's simply not worth it.
You might have gotten me wrong. I don’t want to do something with
it, I wondered if overloading based on attributes is a thing one
has to consider when writing templates or something like that. A
simple test was: Can I define those? If so, what happens on a
function call? The spec doesn’t say anything about it.
As you say, overloads should essentially do the same. Overloads
differing in attributes would differ in implementation details
such that one can make guarantees and the other might give you
better performance or other guarantees. Maybe that’s enough such
that, if both implementations have value, they should differ in
name (or a kind of tag parameter for overload selection).
Filed as https://issues.dlang.org/show_bug.cgi?id=24063
Re: How can overloads be distinguished on attributes alone?
On Monday, July 31, 2023 4:55:44 AM MDT Quirin Schroll via Digitalmars-d-learn
wrote:
> Apparently, functions can be overloaded solely distinguished by
> attributes:
> ```d
> void f(ref int x) pure { x = 1; }
> void f(ref int x) { x = 2; static int s; ++s; }
> ```
>
> I thought that, maybe, a `pure` context calls the `pure` function
> and an impure context calls the impure function, but no: Calling
> `f` leads to an ambiguity error in both contexts. Even if that
> worked, what about inferred contexts, i.e. templates? In simple
> cases, they could forward the contexts in which they are called,
> but you can instantiate a template without calling it.
>
> What am I missing here?
As things stand, the context in which a function is called is irrelevant.
All that matters is the arguments.
And actually, allowing it would complicate any functions that infer
attributes, potentially in a way that wouldn't work. For instance, if you
have a templated function that's trying to infer purity, which one should it
call? If it calls the pure one, it could be pure, but if it doesn't, it
can't be. Either way, because the context isn't yet pure or not, the context
can't be used to determine which should be called. Potentially, the compiler
could just choose the pure function in that case, but the problem gets worse
as you add more attributes.
For instance, what happens when you have a function that's pure but not
@safe and one that's @safe but not pure?
void f() pure {...}
void f() @safe {...}
Should the compiler favor calling the pure one or the @safe one? And what if
you then add something to the function that isn't @safe? If it was calling
the @safe version before, should it switch to the pure one? And if the
functions were @safe pure and @system and not pure instead
void f() @safe pure {...}
void f() @system {...}
then changing the @safety or purity of some of the other code in the
templated function could result in the loss of both attributes. And the more
attributes are involved, the more complex the situation gets.
In effect, we'd be making the attribute inference process have to go in two
directions instead of just going from the bottom up, with the added
complication that it would potentially need to choose between sets of
attributes when choosing which function overload to call.
It's not necessarily the case that we couldn't sort all of this out and come
up with a clean set of rules that allowed functions that infer their
attributes to call the correct function, but it does get pretty complicated,
and it comes with the serious downside that there's no guarantee that the
overloads even do something similar to one another. And when you consider
that it's pretty easy for a change in one part of the code to change which
attributes are inferred in another part of the code, you could easily end up
having a change in one part of your program resulting in drastically
different behavior in a seemingly unrelated part of your program. And even
worse, that change could be because of a library update, making it that much
less obvious which parts of your program could suddenly change behavior due
to a change in attributes.
And I'm probably forgetting other issues that this would add to the mix. So,
while it may very well be possible to do something along the lines of what
you're looking for, I strongly suspect that it's simply not worth it.
- Jonathan M Davis
Re: How can overloads be distinguished on attributes alone?
On Monday, 31 July 2023 at 16:52:03 UTC, Dennis wrote:
On Monday, 31 July 2023 at 16:09:11 UTC, bachmeier wrote:
Is there a reason it would be difficult to make this not
compile?
No, except that might result in code breakage.
The only way you could have code breakage is if you have
```
void f() { }
extern(C) void f() { }
```
but your program never calls f. The fix would be to comment out
one of the duplicate function definitions.
Re: How can overloads be distinguished on attributes alone?
On Monday, 31 July 2023 at 16:09:11 UTC, bachmeier wrote: Is there a reason it would be difficult to make this not compile? No, except that might result in code breakage.
Re: How can overloads be distinguished on attributes alone?
On Monday, 31 July 2023 at 10:55:44 UTC, Quirin Schroll wrote:
What am I missing here?
The duplicate definition check doesn't consider whether a
function is actually unambiguously callable (without e.g. traits
getOverloads), it only prevents creating the same linker symbol
multiple time. So you can even do this:
```D
void f() { }
extern(C) void f() { }
```
But this straight up looks like a bug:
```D
void g() { }
static void g() { } // static doesn't even do anything here
```
How can overloads be distinguished on attributes alone?
Apparently, functions can be overloaded solely distinguished by
attributes:
```d
void f(ref int x) pure { x = 1; }
void f(ref int x) { x = 2; static int s; ++s; }
```
I thought that, maybe, a `pure` context calls the `pure` function
and an impure context calls the impure function, but no: Calling
`f` leads to an ambiguity error in both contexts. Even if that
worked, what about inferred contexts, i.e. templates? In simple
cases, they could forward the contexts in which they are called,
but you can instantiate a template without calling it.
What am I missing here?
