[DIP] Resolution of Alias Template Parameters in Function Templates

Stefanos Baziotis sdi1600105 at di.uoa.gr
Sat May 18 16:52:45 UTC 2019


On Saturday, 18 May 2019 at 16:05:10 UTC, jmh530 wrote:
>
> Thanks for working on this.
>

Your welcome.

>
> You might remove the line
> "People seem to pay money for this feature to be implemented."
> While people (like Ilya and me) are willing to pay for this, 
> it's not really relevant to the technical issues.
>

Good point, this is probably the least edited part of the code. 
It probably came from early draft versions. Removed.

> Also, the forum has been discussing recently using static ifs 
> within a function instead of function overloads. I think the 
> same argument applies here. For instance, if switching to the 
> commented code, then the writeln("here") will get skipped for 
> writeln("there"). Correspondingly, I think it would be nice for 
> the DIP to also discuss resolving is expressions as well.
>

Thanks for the information, I was not aware. But, it's not really 
clear
what the behaviour should be. Look point 2. here [1]. What I 
understand
is that the general idea is to make aliases more identical to 
what they alias
rather than distinguishing them.

This DIP is a step towards that.

That seems to be the direction of the compiler source code as 
well.

On the other hand, the behaviour that you would expect in the 
examples distinguishes them.

In my opinion, I think that there should be a clear direction 
towards the one or the other.
But of course this is not necessarily what you, the community and 
/ or the language
maintainers want. In that case, because it is a matter of 
opinion, it is not (fortunately) up to me to decide. We just need 
to listen to what most people want / care about
along with some rationale backing it up. :)

That is, in what cases they are different and in what they're not.
This could be as simple as "only in `is` case they are different" 
or way
more complicated.


[1] https://dlang.org/spec/declaration.html#alias




More information about the Digitalmars-d mailing list