On Friday, 13 July 2018 at 11:02:57 UTC, RazvanN wrote:
>>> [...]
>
> Indeed, but this was the source of the problem also, because you could
> modify immutable fields that way.
>
>>> [...]
>>
>> Affirmative. The DIP needs to specify how assignment is handled if no opAssign is present but a copy ctor is present. Thanks!
>
> The difference between a copy constructor and opAssign is how the type checking
> is performed. This leads to situations where a copy constructor is not suitable as an assignment operator. However, if a copy

...

> What are your opinions on this?

What about going the other way?

Can you use the unqualified opAssign as the unqualified copy constructor?

I assume these @implicit copy constructors are normal constructors.

On 7/14/18 11:26 AM, Jacob Carlborg wrote:
> On Friday, 13 July 2018 at 01:18:48 UTC, Andrei Alexandrescu wrote:
>> On 7/12/18 2:30 PM, ag0aep6g wrote:
> 
>>> You're still potentially changing the semantics of existing code. `@implicit` can be a UDA today:
>>>
>>> ----
>>> enum implicit = 0;
>>> struct C
>>> {
>>>      @implicit this(ref C another) {}
>>> }
>>> ----
>>>
>>> Today, that's a normal constructor. With the DIP, it becomes a copy constructor.
>>
>> That is correct and a liability of the current DIP. That should be mentioned in it.
> 
> That's easily fixed by implementing a compiler recognized UDA. That would mean that it would only be a copy constructor if "implicit" is defined in core.attribute. This would also avoid any special syntax in the parser. The already existing @selector is implemented like this.

Affirmative. We're going that route, similar to "@safe" and "@nogc".

On 07/16/2018 09:06 PM, Andrei Alexandrescu wrote:
> On 7/14/18 11:26 AM, Jacob Carlborg wrote:
[...]
>> That's easily fixed by implementing a compiler recognized UDA. That would mean that it would only be a copy constructor if "implicit" is defined in core.attribute. This would also avoid any special syntax in the parser. The already existing @selector is implemented like this.
> 
> Affirmative. We're going that route, similar to "@safe" and "@nogc".

@safe and @nogc are not compiler recognized UDAs. If you implement @implicit like them, then you're not doing what Jacob suggests.

On 7/16/18 3:12 PM, ag0aep6g wrote:
> On 07/16/2018 09:06 PM, Andrei Alexandrescu wrote:
>> On 7/14/18 11:26 AM, Jacob Carlborg wrote:
> [...]
>>> That's easily fixed by implementing a compiler recognized UDA. That would mean that it would only be a copy constructor if "implicit" is defined in core.attribute. This would also avoid any special syntax in the parser. The already existing @selector is implemented like this.
>>
>> Affirmative. We're going that route, similar to "@safe" and "@nogc".
> 
> @safe and @nogc are not compiler recognized UDAs. If you implement @implicit like them, then you're not doing what Jacob suggests.

Then "negative" :o). In brief @implicit follows the same implementation as @safe and @nogc/

On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote:
> On 7/14/18 5:03 AM, Luís Marques wrote:
>> If there is "no other meaning of @implicit" (other than the intersection of those two properties) why don't you just call it something like @copyctor?
>
> I'm totally cool with giving the attribute a more obscure name such as @copyctor or anything people want really.
>
> (What follows is a personal opinion.
>
> I think it's better to choose a more general attribute name with reduced initial applicability. Then application of said attribute can be extended to other functions with ease. In contrast, an obscure attribute name is sure to be followed by more obscure attribute names. And don't get me started about inventing new syntax.
>
> Regarding the hand-wringing over generality: we have an exceedingly poor record of paralysis of analysis, whereby we'd worry that every design decision potentially locks us out from all other as-of-yet-unchosen design decisions. If history is any indication, this sudden worry about vaguely-promising green pastures of the future is a sign of malady. We want copy construction. Conflating this with a very general schemata for implicit conversion would not be a wise decision in my opinion. I now deeply regret ever telling Razvan to mention future possible directions. This DIP must do implicit copy constructors and do it well, nothing less and nothing more.)
>
>
> Andrei

I think in this case, a more obscure name like @copyctor is more descriptive. I fear that at some point, a more general attribute like "@implicit" will turn into the next "static". To me, @implicit smells like one of those keywords that will grow to carry many different meanings in different contexts and just end up overly-broad.

-Jon

On Mon., 16 Jul. 2018, 6:00 pm docandrew via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote:
> > On 7/14/18 5:03 AM, Luís Marques wrote:
> >> If there is "no other meaning of @implicit" (other than the intersection of those two properties) why don't you just call it something like @copyctor?
> >
> > I'm totally cool with giving the attribute a more obscure name such as @copyctor or anything people want really.
> >
> > (What follows is a personal opinion.
> >
> > I think it's better to choose a more general attribute name with reduced initial applicability. Then application of said attribute can be extended to other functions with ease. In contrast, an obscure attribute name is sure to be followed by more obscure attribute names. And don't get me started about inventing new syntax.
> >
> > Regarding the hand-wringing over generality: we have an exceedingly poor record of paralysis of analysis, whereby we'd worry that every design decision potentially locks us out from all other as-of-yet-unchosen design decisions. If history is any indication, this sudden worry about vaguely-promising green pastures of the future is a sign of malady. We want copy construction. Conflating this with a very general schemata for implicit conversion would not be a wise decision in my opinion. I now deeply regret ever telling Razvan to mention future possible directions. This DIP must do implicit copy constructors and do it well, nothing less and nothing more.)
> >
> >
> > Andrei
>
> I think in this case, a more obscure name like @copyctor is more descriptive. I fear that at some point, a more general attribute like "@implicit" will turn into the next "static". To me, @implicit smells like one of those keywords that will grow to carry many different meanings in different contexts and just end up overly-broad.
>

But that's the point, and the key advantage of the name ;)

On Tuesday, 17 July 2018 at 00:04:12 UTC, Andrei Alexandrescu wrote:

> Then "negative" :o). In brief @implicit follows the same implementation as @safe and @nogc/

Why? This is a breaking change. Why not go with an approach that does not cause any breaking changes, which is just as easy to do? It also doesn't required any special casing in the parser. This is how @selector is implemented.

--
/Jacob Carlborg

On 7/16/18 8:57 PM, docandrew wrote:
> I think in this case, a more obscure name like @copyctor is more descriptive.

On the contrary, it is redundant and uninformative. It applies to exactly a constructor that copies, so it adds no information. "@implicit" describes precisely what the attribute does.

On 7/17/18 12:04 AM, Manu wrote:
> But that's the point, and the key advantage of the name ;)

[:nod:]

On Tuesday, 17 July 2018 at 07:27:32 UTC, Jacob Carlborg wrote:
> On Tuesday, 17 July 2018 at 00:04:12 UTC, Andrei Alexandrescu wrote:
>
>> Then "negative" :o). In brief @implicit follows the same implementation as @safe and @nogc/
>
> Why? This is a breaking change. Why not go with an approach that does not cause any breaking changes, which is just as easy to do? It also doesn't required any special casing in the parser. This is how @selector is implemented.
>
> --
> /Jacob Carlborg

Can you explain a bit more here? How does having implicit as a compiler recognized UDA avoid breaking changes as opposed to it being implemented like @nogc/@safe (how are those implemented differently anyway?)

Cheers,
- Ali