The DIP Process

[Manu]

On Tue, Feb 26, 2019 at 5:34 PM H. S. Teoh via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Tue, Feb 26, 2019 at 06:12:45PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> > On Tuesday, February 26, 2019 5:53:51 PM MST Nicholas Wilson via
> > Digitalmars-d wrote:
> [...]
> > > FWIW Walter has said that if alias this had been proposed today that
> > > it would be rejected because it has too many nasty corner cases. I
> > > happen to believe alias this is awesome but I do see where he's
> > > coming from and I've been reviewing a lot of Razvan's PRs fixing
> > > those corner cases so I know they do exist. One of the points on the
> > > agenda for the DLF meeting at dconf is a review of the state of
> > > alias this.
> >
> > It's one of those features that's occasionally useful, but in general,
> > I'm inclined to think that it causes way more trouble than it's worth.
> > Honestly, implicit conversions in general tend to be problematic much
> > as they can be really nice to have sometimes. They're particularly bad
> > when templates get involved.
> [...]
>
> I'm a pretty heavy user of alias this, and would be quite unhappy if the
> present semantics were to change or become deprecated or otherwise cease
> being supported.  I understand there are some dark corner cases where
> it's not at all obvious what the "correct" behaviour is, but still,
> alias this does offer significant value for arithmetical types and
> wrapper types.  I'd even say that in many cases, it *helps* with
> templates because it lets you make your custom type work with a template
> that doesn't (and shouldn't) know about the specifics of your type.
>
> Where it breaks down is when templates are written with assumptions that
> don't come directly from introspection.  Then you start getting into
> ambiguous corner cases and other nasty unexpected behaviours.
>
> Anyway, if anything were to change with alias this, we'd better have a
> darned good replacement for it, because I'll be expecting it!

I use `alias this` a lot, but that's just because it's the only tool we have.
`@implicit` constructors (and/or cast operators) would resolve all
uses I can think of, and I think the rules on those would be much
simpler.