Implicit Constructors

[Steven Schveighoffer]

On 10/13/17 9:23 AM, rikki cattermole wrote:
> On 13/10/2017 2:07 PM, Steven Schveighoffer wrote:
>> On 10/13/17 9:04 AM, rikki cattermole wrote:
>>> Lets just kill it.
>>>
>>> It's an ugly unexpected piece of syntax.
>>
>> It may be used somewhere, and then what is the migration path for 
>> those people? I don't see that it's harming anything having it there, 
>> most of us didn't even know about it.
> 
> 1) Warning, then actual removal. It'll still be available for a few 
> releases for people to update their code
> 2) Fairly simple replacement: new Foo(0)

It's not that simple:

void foo(alias x)()
{
    x(0); // can't replace this with x(Foo(0))
}

void bar(int x);
void baz(Foo x ...);

foo!bar();
foo!baz();

> 
> 
>> It's also not necessary to remove the feature in order to build a 
>> library that does similar things, and the syntax isn't needed elsewhere.
>>
>> It is bizarre, though, that it works only for classes and builtins, 
>> and not for structs.
>>
>> I have experienced with Swift the team killing "ugly" features, and 
>> it's painful.
> 
> And yet I expected the 0 there to be null. It would make a whole lot 
> more sense then allocating a new instance which is considerably more 
> expensive operation and not even used anywhere else!

0 does not implicitly cast to null in D.

I would have expected a stack allocation of the object. That would be 
consistent with other typesafe variadics:

void foo(int[] x ...);

foo(1, 2, 3); // allocate array on the stack

It even says in the spec that storing the class reference somewhere else 
is a bad idea because it *could* allocate on the stack.

-Steve