July 13, 2018
On 7/13/18 12:06 PM, xenon325 wrote:
>  From the DIP:
>> The copy constructor declaration will be recognized by the parser when the tokens @, implicit, this are encountered exactly in this order
> 
> Regarding "exactly in this order". The code below would be allowed and define copy c'tor for `A` and usual c'tor for `B` ?
> 
> 
>      struct implicit{}
> 
>      struct A {
>          @safe @implicit this(ref A) {}
>      }
> 
>      struct B {
>          @implicit @safe this(ref B) {}
>      }

We'll change that part to accept the standard attribute syntax.

July 13, 2018
On Friday, 13 July 2018 at 16:02:51 UTC, Andrei Alexandrescu wrote:
> On 7/13/18 11:14 AM, Atila Neves wrote:
>> On Friday, 13 July 2018 at 14:12:59 UTC, Andrei Alexandrescu wrote:
>>> On 7/13/18 8:31 AM, Atila Neves wrote:
>>>> On Friday, 13 July 2018 at 03:01:25 UTC, Manu wrote:
>>>>> [...]
>>>>
>>>> https://github.com/search?q=%22this%5C%28ref%22+language%3AD&type=Code
>>>>
>>>> The answer seems to be: not many. Most of the results above are false positives because github won't let me escape the left parenthesis.
>>>
>>> A proposal that just works without any user intervention would definitely be attractive.
>>>
>>> The drawback is silent modification of code behavior. Consider:
>>>
>>> import std.stdio;
>>> struct A {
>>>     this(ref immutable A obj) { writeln("x"); }
>>> }
>>> void main()
>>> {
>>>     immutable A a1;
>>>     A a2 = A(a1);
>>>     A a3 = a1;
>>> }
>>>
>>> With the current language, "x" is printed once. If we make the ctor implicit, "x" is printed twice.
>>>
>>> In the "levels of hell" of semantics changes, probably the nicest is allowing code to compile that previously didn't. Then, refusing to compile code that previously did would be definitely bad. But if you want to drink the cup of disgrace to the bottom, you must reach for silent change of behavior.
>> 
>> I agree on the levels of hell. I wasn't aware the kind of change above would happen - methinks it should be in the DIP.
>
> Great. Razvan, can you please add this example with discussion to the DIP (probably at the end of the Motivation section as an explanation why we need the addition of @implicit). Thanks.
>
>> I think I now even understand why `@implicit` is there to begin with. I still think it's confusing, so imagine someone new to the language.
>
> Interesting. Coming from a C++ background makes the matter obvious because there's plenty of implicit vs. explicit discussion. To compensate for my bias - what do you think would be a better attribute name?

I came to D via C++ as well. Maybe my brain short-circuited because I saw `A a3 = a1;` in a discussion about copy constructors and assumed it would be called, and didn't realise it wouldn't have been before. I just took for granted the implicitness of the constructor call, since that's what C++ does!

I wasn't even aware one could declare a C++ copy constructor `explicit` until I tried it just now. It's just not something I've ever thought about.

Now that I understand the implicit call `@implicit` makes sense to me but I'm convinced it'll confuse more people than not. I'll see if I can come up with a better name.

Atila
July 13, 2018
On Fri, 13 Jul 2018 at 04:05, RazvanN via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> > [...]
>
> The problem with this approach is that some copy constructors will also be used as assignment operators while others will not, but with good error messages it could be handled (error on line `f = d` : opAssign not specified and the copy constructor is not suitable for assignments because it modifies immutable field `b`).
>
> What are your opinions on this?

Right; I figure, if the struct contains members that can't be copied,
then the struct is defined in such a way that it simply can't be
copied.
I mean, if the copy constructor can't be used to copy the thing, then
is copying the struct valid at all?

What would a valid copy operation on a struct with an immutable field do? Either way, in that case, a good error should inform the user they need to write an explicit opAssign.
July 13, 2018
On Fri, 13 Jul 2018 at 07:40, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 7/12/18 11:01 PM, Manu wrote:
> > What existing code are you changing the semantics of?
> > It's still not clear to me how accepting `this(ref T)` as a magic
> > signature that is a copy constructor can break existing code?
> > Is it the unlikely^^2 case that the function exists somewhere and
> > doesn't perform copy construction?
> >    1. the function is highly unlikely to exist because postblit; it's a
> > meaningless function to write. are there any known instances of that
> > signature in the wild?
> >    2. if the function does exist, it's highly unlikely that it doesn't
> > perform a valid copy construction; what else could it possibly do?
> >    3. remaining cases are broken by this DIP, but they are probably
> > crazy and deserve to be deprecated!
> >
> > Is there any reasonable existing use of the signature that would be
> > legitimately broken by being invoked implicitly?
> > I feel like there's something that I'm missing... but if there's not,
> > then just change the semantic.
> >
> > I reason; copy construction is something so fundamental. It will be
> > written by basically every programmer with relative high frequently,
> > and adding awkward syntax or weird language baggage to the concept
> > feels like a very poor choice.
> > By contrast, if there's 1 user out there who used the copy-constructor
> > signature to do some weird thing other than copy construction, and
> > their code is broken by this change, his use case does not balance the
> > imposition applied to every implementation of copy constructor forever
> > from this time forward.
> > This is so much more important than that, it's extremely fundamental
> > language stuff, and needs to be as friction-less as possible, and it
> > should certainly not reek of legacy drama.
>
> Noted. So in summary you would be okay with changing semantics of existing code, under the intuition that the change is unlikely to be destructive anyway.

Yes, I think this is too important and fundamental to lug historical baggage along with it for the rest of time.

That said, I'm firmly in favour of @implicit, but the terms of
introduction here are not satisfying.
If we're going to add yet another attribute, I want to know it's a
really good attribute. Adding a whole new attribute just as a marker
in this case, and no clear sign that it may or may not be developed
into an obvious extension of the concept (and what that looks like) is
not satisfactory grounds to introduce a new attribute.
I don't understand your objection to this point. I feel like you of
all people should be arguing this case.

If the DIP specifies introduction of an attribute, then I can't see how there's not a dependency on specification of the attribute. (That doesn't necessarily mean it must be implemented all at once, but I feel like the spec/intent should be presented up-front)
July 13, 2018
On Fri, 13 Jul 2018 at 10:35, Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> [...]
>
> Now that I understand the implicit call `@implicit` makes sense to me but I'm convinced it'll confuse more people than not. I'll see if I can come up with a better name.

You don't find 'implicit' satisfactory as an obvious and intuitive
complement to 'explicit' in C++?
I think the name's perfect, but I need to know it works in general to
find it acceptable.
As a marker used in this one case, it's a terrible name, as a
generalised concept, it's perfect.
July 13, 2018
On Friday, 13 July 2018 at 18:54:48 UTC, Manu wrote:
> As a marker used in this one case, it's a terrible name, as a
> generalised concept, it's perfect.

Exactly.
July 13, 2018
On Fri, 13 Jul 2018 at 07:35, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 7/12/18 11:45 PM, Manu wrote:
> >
> > I can see myself getting behind 2 possibilities, no @implicit, or @implicit done right.
>
> A couple of simple ideas are making the process productive. One is to rely on facts instead of feelings. "It's weird" or "I don't like it" are less helpful than "semantics of this or that case are not covered".

What "I don't like" is using an attribute as a marker, and especially
in the unique case of a copy constructor, which is so fundamental to
the language.
If it has a systemic meaning, as it's sort-of proposed that maybe it
might in the future sometime, then it's fine.

There's a lot of subjectivity in programming. I don't like that python
has significant white-space. I don't like that Javascript isn't a
native language.
I don't like the idea of introducing an attribute as a marker in a
single case, without some expectation that it has a future beyond
that.

> Another is precision. Stating vague goals and standards ("I want @implicit done well") and systematically asking others to actually put in the work is less desirable than providing concrete, motivated, actionable feedback.

As I originally said, my feedback is concrete: specify @implicit, this
DIP depends on it.
My language like "@implicit done right" came later, as a reference to
prior comments.

As I've said, I actually really want @implicit, but I want to be satisfied by it's definition and somewhat convinced that it has a future, and specifically, that it's NOT just a marker to be used in this case.

It's not about 'asking others to put in the work', this DIP has a
dependency on it, so it can't not be defined. The definition is
currently "it's a marker, and maybe we might do something in the
future", and that's a poor definition.
If I presented a DIP which casually dropped in a new attribute, you
would absolutely insist that I specify it.

> To the second point: we have a history of defining features too permissively, to then regret not having waited to accumulate experience. Starting with a restricted version then building on experience with it seems to be a much better strategy. From that perspective, introducing implicit only for restricted copy construction seems like a good step that doesn't take others, without precluding them.

There's also @property... and 'scope' as existed prior DIP1000, and 'in'.
I think this thing needs at least a little spec-ing. If it's clear up
front that it's not going anywhere (easily shot-down or whatever),
then it's not a good choice.
If it looks generally promising for the future, and there's no obvious
roadblocks for wider deployment, then we're good, and I'll desist on
this point.
I don't know how we can be confident of that without at least a little
exploration.

> > I don't see myself getting behind introduction of @implicit on such terms that it's nothing but "a marker for the copy constructor". So this 'mountain' is critical to understanding whether I can support this DIP as proposed or not.
>
> I'd put it a slightly different way. "Getting behind" and "supporting or not" suggests a position of power and an emphasis on the politics of the process. The natural counter to this would be asking whether your support is necessary, which put us all in a very unproductive position.

Presenting a proposal to the community is an implicit request for
support. I'm not saying I have any power further than my reading of
the proposal and sharing my own judgement of its merit.
You can do whatever you do... I'm just saying what I find satisfying,
and this proposal is not satisfying without some further
substantiation of the proposed new attribute.

> The right emphasis is not getting your support on a given DIP, but instead us all benefiting of your active contribution to a better DIP.

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.
My feeling is inspired by '@property', 'scope', 'in'. We don't need
any more events like those.
July 14, 2018
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.
July 13, 2018
On Friday, 13 July 2018 at 21:49:57 UTC, 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.

I'm not crazy about it either, but it may be a necessary evil to avoid breaking code (although it doesn't entirely avoid that, as has been demonstrated).
July 13, 2018
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.

Sadly we got to irreducible positions once again: you and I used different definitions for common terms like "define", "specify", "explain", "contribute", and then you use them to ask questions or make demands, all of which I'm sure you find reasonable. But I am unable to understand them, let alone take them under advisement when working on the DIP. (I did understand your reference to the assignment and will work on that, thanks much.) You will need to forgive me for the scarcity of my future answers - but believe me I will do my best to derive value from your feedback.


Andrei