struct Test { int i; alias i this; }
auto testFunct( Test i){ }

void main() {
    Test t;
    t = 1;
    testFunct( 1);
}


The assignment is fine, but the call is rejected by dmd.

See also
http://forum.dlang.org/post/fqfonkcdcjuwbaacqshe@forum.dlang.org

On Monday, 22 February 2016 at 17:22:51 UTC, Carl Sturtivant wrote:
> struct Test { int i; alias i this; }
> [...]
> The assignment is fine, but the call is rejected by dmd.


    Test t = 1;

is rejected too because alias this is not a constructor and a function call would be construction.

I do think it would be very nice to have explicitly implicit constructors which would cover both these cases (then we can do user-defined types that accept the null literal in function calls too just like built in arrays!), but I don't think it has anything to do with alias this.

On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote:
> On Monday, 22 February 2016 at 17:22:51 UTC, Carl Sturtivant wrote:
>> struct Test { int i; alias i this; }
>> [...]
>> The assignment is fine, but the call is rejected by dmd.
>
>
>     Test t = 1;
>
> is rejected too because alias this is not a constructor and a function call would be construction.
>
> I do think it would be very nice to have explicitly implicit constructors which would cover both these cases (then we can do user-defined types that accept the null literal in function calls too just like built in arrays!), but I don't think it has anything to do with alias this.

explicitly-implicit constructors are badly needed, I could write an essay on this

On Mon, Feb 22, 2016 at 06:07:26PM +0000, rsw0x via Digitalmars-d wrote:
> On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote:
> >On Monday, 22 February 2016 at 17:22:51 UTC, Carl Sturtivant wrote:
> >>struct Test { int i; alias i this; }
> >>[...]
> >>The assignment is fine, but the call is rejected by dmd.
> >
> >
> >    Test t = 1;
> >
> >is rejected too because alias this is not a constructor and a function call would be construction.
> >
> >I do think it would be very nice to have explicitly implicit constructors which would cover both these cases (then we can do user-defined types that accept the null literal in function calls too just like built in arrays!), but I don't think it has anything to do with alias this.
> 
> explicitly-implicit constructors are badly needed, I could write an essay on this

AFAICT, implicit ctors are not supported by design.


T

-- 
Ruby is essentially Perl minus Wall.

On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote:
> On Mon, Feb 22, 2016 at 06:07:26PM +0000, rsw0x via Digitalmars-d wrote:
>> On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote:
>> >[...]
>> 
>> explicitly-implicit constructors are badly needed, I could write an essay on this
>
> AFAICT, implicit ctors are not supported by design.
>
>
> T

It is a bad design.

On Mon, Feb 22, 2016 at 06:20:09PM +0000, rsw0x via Digitalmars-d wrote:
> On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote:
> >On Mon, Feb 22, 2016 at 06:07:26PM +0000, rsw0x via Digitalmars-d wrote:
> >>On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote:
> >>>[...]
> >>
> >>explicitly-implicit constructors are badly needed, I could write an essay on this
> >
> >AFAICT, implicit ctors are not supported by design.
> >
> >
> >T
> 
> It is a bad design.

Don't shoot the messenger. Take it up with Walter / Andrei.


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte

On 02/22/2016 08:20 PM, rsw0x wrote:
> On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote:
>> On Mon, Feb 22, 2016 at 06:07:26PM +0000, rsw0x via Digitalmars-d wrote:
>>> On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote:
>>> >[...]
>>>
>>> explicitly-implicit constructors are badly needed, I could write an essay on this
>>
>> AFAICT, implicit ctors are not supported by design.
>>
>>
>> T
> 
> It is a bad design.

It is arguable opinion.

On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote:
> AFAICT, implicit ctors are not supported by design.

I agree with them that implicitly implicit ctors are a bad design, but explicitly implicit ctors I think are a different issue because then it is clear that the designer intended it and we can ask if it is sane to use or not.

Explicitly implicit ctors are like:

struct Foo {
   @implicit this(int a) {}
}

since it has the attribute, the compiler will allow it to be used when calling a function that expects a Foo using an int (unless some other thing matches better).

Calling that explicitly is already allowed:

Foo a = 1; // works with that now

On Monday, 22 February 2016 at 18:28:04 UTC, Dicebot wrote:
> On 02/22/2016 08:20 PM, rsw0x wrote:
>> On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote:
>>> On Mon, Feb 22, 2016 at 06:07:26PM +0000, rsw0x via Digitalmars-d wrote:
>>>> On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote:
>>>> >[...]
>>>>
>>>> explicitly-implicit constructors are badly needed, I could write an essay on this
>>>
>>> AFAICT, implicit ctors are not supported by design.
>>>
>>>
>>> T
>> 
>> It is a bad design.
>
> It is arguable opinion.

Yeah. Sometimes having implicit conversions is great. Other times, it creates tons of problems. C++ allows a lot of implicit stuff, and it becomes really easy to have unexpected conversions going on, and it can be difficult to figure out exactly what code is being called. For the most part, D doesn't have any of those problems, but it arguably loses some usability as a result. So, it's highly debatable.

Personally, I think that the big place that implicit conversions are a disaster is generic code. It makes it really easy to have stuff pass template constraints due to implicit conversions and then have the wrong behavior inside the templated code, because the conversion is never forced, and it doesn't act the same way as it would if the conversion had been forced and possibly even ends up being converted for some of expressions in the function and not converted in others. For non-templated code, it's a lot more debatable, but when it comes to templated code, I really wish that alias this didn't exist.

- Jonathan M Davis

On Tuesday, 23 February 2016 at 01:02:21 UTC, Jonathan M Davis wrote:
> Yeah. Sometimes having implicit conversions is great. Other times, it creates tons of problems. C++ allows a lot of implicit stuff, and it becomes really easy to have unexpected conversions going on, and it can be difficult to figure out exactly what code is being called. For the most part, D doesn't have any of those problems, but it arguably loses some usability as a result.

Don't we already have implicit conversions with alias this, so what's the deal?

struct A { int i; alias i this; }
void f(int i){}
void f(string s){}
void g(A a){ f(a); } //what's called?