UFCS for struct opCall?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Apr 9 09:22:08 PDT 2013


On 4/9/13 12:16 PM, deadalnix wrote:
> On Tuesday, 9 April 2013 at 15:56:10 UTC, Andrei Alexandrescu wrote:
>> On 4/9/13 11:43 AM, deadalnix wrote:
>>> On Tuesday, 9 April 2013 at 15:29:42 UTC, Andrei Alexandrescu wrote:
>>>> They are different than regular functions by necessity. A constructor
>>>> must start on an raw object ("unprepared" in a sense) and bring it to
>>>> a meaningful state. In the case of immutable and const objects, that
>>>> grants the constructor special characteristics that are very unlike
>>>> regular functions. So they are special.
>>>>
>>>
>>> They need magic inside, it doesn't need to leak outside.
>>
>> Agreed.
>>
>>> As now they are rvalues, this is easy to type the constructor as
>>> follow :
>>>
>>> struct S {
>>> T t;
>>>
>>> this(T t) {
>>> this.t = t;
>>> }
>>>
>>> // Becomes.
>>> static S __ctor(T t) {
>>> S this = S.init; // Magic !!
>>> this.t = t;
>>> return this; // Magic !!
>>> }
>>> }
>>>
>>> The magic don't need to leak outside.
>>
>> I'm lost.
>>
>> Andrei
>
> What I'm saying is that no magic need to be done outside the
> constructor, and it can be considered as a regular function.
>
> For instance, in the code snippet above, the constructor can be
> translated into the __ctor function (in D like) by adding the magic.
>
> This would allow to merge constructors and functions, and handle both
> the same way.

How do you address construction of immutable objects?

Andrei


More information about the Digitalmars-d mailing list