Jonathan M Davis via phobos
phobos at puremagic.com
Tue Oct 27 10:44:14 PDT 2015
On Tuesday, October 27, 2015 10:28:25 Andrei Alexandrescu via phobos wrote:
> That is sensible. However, another way to look at it is:
> 1. "alias this" implements subtyping
> 2. By using "alias this" with string, DirEntry is subtyping the string type
> 3. A subtype of a range should be a range
> Therefore, DirEntry is a range so the language needs to figure how to
> treat it as such.
> To some extent I'm playing devil's advocate because I foresee the
> difficulties in making this work.
While I understand that way of looking at it, I think that in this case at
least, it would just be cleaner to get rid of the implicit conversion.
Personally, I've found it to be very annoying even without the problems that
we have here, since it means that dirEntries does horribly with anything
involving type inference (including foreach).
And I'd argue that conceptually string is _not_ a sub-type of DirEntry. It's
just the only way that we have to implement an implicit conversion. So,
while it might be nice in the cases where you explicitly assign or
initialize a string with a DirEntry, in pretty much all other cases, you
don't want that conversion to take place, and the fact that it exists is
just problematic. This would work far better if we had a way to tell the
compiler that if the code tries to convert a DirEntry to a string that it
should then use the name property of the DirEntry but also tell the compiler
that that conversion should not be used in any kind of type inference (so we
get an implicit conversion but no sub-typing). However, we don't have that
and instead have the far more blunt (and problematic) alias this.
Honestly, it's issues like this which make it so that I think that using
alias this is usually a bad idea. It can work reasonably well when templates
and introspection aren't involved, but once they are, alias this tends to
break things very quickly.
- Jonathan M Davis
More information about the phobos