alias this constructor

[Jonathan M Davis]

On Sunday, March 25, 2018 06:24:35 Shachar Shemesh via Digitalmars-d wrote:
> On 25/03/18 04:51, Jonathan M Davis wrote:
> > On Sunday, March 25, 2018 00:47:20 Dave Jones via Digitalmars-d wrote:
> >> struct Foo
> >> {
> >>
> >>       int x;
> >>       alias x this;
> >>
> >> }
> >>
> >> Foo f = 12; // error
> >>
> >> Foo foo;
> >> f = 12;     // this is OK
> >>
> >> any reason why the first cant be allowed?
> >
> > Because it was deemed to cause too many problems. C++ code can have
> > quite a few problems related to all of the implicit conversions it
> > allows with stuff like constructing objects. Walter decided that D
> > would be better off if it did not allow such conversions, and as such,
> > D is much pickier about implicit conversions in general.
>
> That's a good reason to disallow assignment from int to Foo. I see zero
> sense in allowing assignment and disallowing construction.
>
> *****
>
> Technically, I understand the mechanisms at play here. During
> construction, this is a Foo object, and it has no construction from int.
> During assignment, we are allowed to convert a Foo lvalue to a Foo.x
> (int) lvalue, and that gets assigned.
>
> Despite understanding the mechanics, I find the end result surprising
> and unexpected. D makes it damn easy to implicitly expose an inner
> member, and much more difficult to actually do this safely (you have to
> create a property and then alias this that property).

Having something like opImplicitCast would arguably have been better than
alias this.

> If I'd be building C++ today, I'd replace the "explicit" keyword with
> "implicit" (i.e. - still allow single var constructors to become
> implicit conversion ops, but make that transformation an opt-in rather
> than an opt-out feature). I think that would have been a much better
> approach than what D took.

That would be a significant improvement for C++, though over time, I've
increasingly become of the opinion that adding implicit conversions to
user-defined types is more trouble than it's worth. There are certainly
times when it's useful, but it causes enough problems that I'm not at all
convinced that it's ultimately a feature worth having. And with the route
that D went, implicit conversions are arguably crippled anyway. So, we have
a partial solution that isn't really enough to cleanly use implicit
conversions when it might be appropriate, but what we have is still enough
to cause problems.

- Jonathan M Davis