On 7/13/18 5:49 PM, rikki cattermole wrote:
> On 14/07/2018 9:28 AM, Manu wrote:
>> I've already contributed other points to this DIP in the way you describe.
>> This one however is very strange, and I'm surprised you can find the
>> hand-wavy introduction of a new attribute without any sense of where
>> it's going to be okay. Or maybe, I'm surprised I'm the only one that
>> finds problem with that.
> 
> You are very much not alone.
> 
> I didn't articulate it very clearly, but I am super not happy with such a new attribute.

It's a very simple process - @implicit is not invented as much as a given.

We need to distinguish a constructor from other constructors.

The constructor supports attributes.

Attributes are a mechanism for distinguishing declarations from other declarations.

Ergo, an attribute is the mechanism of choice.

Done deal.

=====

If we don't like the use of an attribute, it means we somehow failed in defining attributes in the first place. (I don't think we did; attributes as defined in D are brilliant and currently underused.) It's poor language design to define a mechanism for doing a category of Xs and then explicitly avoiding it exactly when the opportunity of doing X arises.

From that vantage point, the choice of an attribute to identify implicit copy construction is unassailably obvious, and elucubrated syntax inventions such as "@this", "this(ref this x)" are chucklesomely profligate and ridiculously baroque.


Andrei

On Fri, 13 Jul 2018 at 17:45, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 7/13/18 5:28 PM, Manu wrote:
> > As I originally said, my feedback is concrete: specify @implicit, this DIP depends on it.
>
> The specification of @implicit is in the DIP in full: a constructor that takes by reference a qualified typeof(this) and has the @implicit attribute will be callable implicitly by the compiler. There is no other meaning of @implicit. That completes the spec of @implicit.

Right, and this is 100% of my concern here.
To introduce a new attribute for such a one-off purpose feels like a
poor choice, and on those terms I would rather see the feature work
with no such attribute (as we've considered in the other fork). If you
assess the likelihood of actually breaking code in the wild (I expect
it's super slim; data would be nice), you might find that the risk is
satisfactory.

However, the DIP alludes to a possible future for the attribute, and I
think that text is intended to make us feel better about the
introduction of the attribute, but I would be a lot more comfortable
with a more substantial support of its introduction.
Basically, and you already know this; I think it's a weird choice to
introduce a new attribute for this one-off case, but as a systemic
feature which addresses a general long-standing problem, it feels like
a good and logical solution.

I think we need some idea if the broader application is even
theoretically workable up-front. If there's obvious issues with the
idea of deploying @implicit generally, then we shouldn't deploy it
here, and instead, we should deploy something else here which CAN
successfully be generalised in the future.
Determining that requires at least a cursory exploration.

On Fri, 13 Jul 2018 at 18:00, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 7/13/18 5:49 PM, rikki cattermole wrote:
> > On 14/07/2018 9:28 AM, Manu wrote:
> >> I've already contributed other points to this DIP in the way you
> >> describe.
> >> This one however is very strange, and I'm surprised you can find the
> >> hand-wavy introduction of a new attribute without any sense of where
> >> it's going to be okay. Or maybe, I'm surprised I'm the only one that
> >> finds problem with that.
> >
> > You are very much not alone.
> >
> > I didn't articulate it very clearly, but I am super not happy with such a new attribute.
>
> It's a very simple process - @implicit is not invented as much as a given.
>
> We need to distinguish a constructor from other constructors.
>
> The constructor supports attributes.
>
> Attributes are a mechanism for distinguishing declarations from other declarations.
>
> Ergo, an attribute is the mechanism of choice.
>
> Done deal.
>
> =====
>
> If we don't like the use of an attribute, it means we somehow failed in defining attributes in the first place. (I don't think we did; attributes as defined in D are brilliant and currently underused.) It's poor language design to define a mechanism for doing a category of Xs and then explicitly avoiding it exactly when the opportunity of doing X arises.
>
>  From that vantage point, the choice of an attribute to identify
> implicit copy construction is unassailably obvious, and elucubrated
> syntax inventions such as "@this", "this(ref this x)" are chucklesomely
> profligate and ridiculously baroque.

But you surely recognise that D has a lot of intrinsic attributes
already, and that's a lot of mental (and visual) baggage to carry
around.
If we add a new intrinsic attribute, I would want to be sure it's
widely useful, because every D user will need to learn about and
understand it.
It's much easier to learn, and more useful knowledge to have, if it
has a broad meaning which solves a general class of problem, than just
a marker that you need to remember you have to type in one specific
niche location.

On 14/07/2018 1:04 PM, Manu wrote:
> Determining that requires at least a cursory exploration.

Given how many of us are objecting to the syntax, I'm going to place this requirement upon a 'yes' answer by me. That an attempt is made for an alternative syntax discussion. It's a fair request I think.

On Saturday, 14 July 2018 at 00:41:37 UTC, Andrei Alexandrescu wrote:
> The specification of @implicit is in the DIP in full: a constructor that takes by reference a qualified typeof(this) and has the @implicit attribute will be callable implicitly by the compiler. There is no other meaning of @implicit. That completes the spec of @implicit.

That is the problem: you are using a very generic name ("implicit") to signify both:

1) something very general ("will be callable implicitly by the compiler") and

2) something very specific ("a constructor that takes by reference a qualified typeof(this)")

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?

On the other hand, if the name is chosen with the hope that the meaning will be generalized in the future ("callable implicitly by the compiler"), why don't you want to at least briefly discuss that more general meaning?

What happens if you later conclude that a generic "callable implicitly by the compiler" annotation has semantics that don't quite align with those of this ctor annotation? Do you need to introduce @implicitconv?

Surely we want the language constructs to be composable and generalizable, and not just quirky one offs that you have to memorize. This seems like a missed opportunity to make sure of that.

On Sat., 14 Jul. 2018, 2:00 am rikki cattermole via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> On 14/07/2018 1:04 PM, Manu wrote:
> > Determining that requires at least a cursory exploration.
>
> Given how many of us are objecting to the syntax, I'm going to place this requirement upon a 'yes' answer by me. That an attempt is made for an alternative syntax discussion. It's a fair request I think.
>

I just want to reiterate again, I'm not seeking alternative syntax, I just want to know that proposed syntax can work broadly, or if there are any challenges or problems that would restrict it from broad application.

>

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

On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote:
> 
> 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.

Strongly agree with this.
In my review on Github I had a few sentences about this, but I removed them because I thought it may be perceived wrong. I find it almost completely irrelevant to add a "future directions" discussion to a DIP. If a DIP is incomplete, then finish it. Other than that, a DIP should stand completely on its own, regardless of speculation on future directions.

-Johan

On 14/07/2018 11:49 PM, Johan Engelen wrote:
> On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote:
>>
>> 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.
> 
> Strongly agree with this.
> In my review on Github I had a few sentences about this, but I removed them because I thought it may be perceived wrong. I find it almost completely irrelevant to add a "future directions" discussion to a DIP. If a DIP is incomplete, then finish it. Other than that, a DIP should stand completely on its own, regardless of speculation on future directions.
> 
> -Johan

Really any mention of the "future" in a DIP section wise, should be fairly concrete.

I.e. this is already a good design, BUT it may come to pass that this use case is indeed important to support (an acknowledgement to its existence) so here is an idea on how to support it.

It doesn't need to be entirely thought out, it just needs to be pretty well thought out and with clear added complexity as to why it isn't part of the original DIP.

The example I'll use is my named arguments DIP[0], where I show a feature that could be added to allow renaming of args. However, because I'm unconvinced that such a complex feature is even needed, I don't support it.

[0] https://github.com/rikkimax/DIPs/blob/named_args/DIPs/DIP1xxx-RC.md#future-proposals

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.

--
/Jacob Carlborg