On 07/12/2018 09:49 AM, Atila Neves wrote:
> On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:
> 
>> [...]
> 
>> If by "come in pairs" you mean that you can define them both, then yes,
>> that is the case. Will add a paragraph in the DIP to specify this.
>>
>> You mentioned that it's terrible that the assignment operator
>> and the copy constructor come in pairs. Why is that? Would you rather
>> have a copy constructor that is used also as an assignment operator?
> 
> Because, like in C++, now you have to implement both and make sure they do the same thing. Boilerplaty and a recipe for disaster.
> 
> Atila

There's no meaningful way to avoid that. The two operations are fundamentally different, are typechecked differently, and actually are different in the presence of qualifiers on fields.

Introspection is a key helper here compared to C++.

On Thursday, 12 July 2018 07:45:30 MDT Andrei Alexandrescu via Digitalmars-d wrote:
> > I also very much dislike the syntax - it makes no sense to me at all. I commented on the PR itself asking why it differs so much from C++ - specifically, what's bad about the C++ way of doing things there that we want to avoid?
>
> C++ is at the other end of the spectrum - constructors are too implicit, so the "explicit" keyword has been introduced with the advice to use it in the vast majority of cases. If C++ could do it again, it would make everything explicit and add an "implicit" keyword.

That's only an issue in C++, because C++ uses constructors for implicit conversions unless you mark them with explicit. D doesn't ever do implicit conversions like that. All constructors are effectively explicit. Is this DIP proposing that we add such implicit conversions? Because if it is, that's a pretty major change that arguably has nothing to do with copy constructors, since copy constructors are for constructing an object from another object of the same type (though possibly of different mutability), not from objects of other types. That would just be a normal constructor.

I really don't understand what the purpose of @implicit is here. What's the problem of just going off of the type of the constructor's single parameter to determine whether it's a copy constructor?

- Jonathan M Davis

On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
> I managed to put together a first draft of the DIP for adding the copy constructor to the language [1]. If anyone is interested, please take a look. Suggestions and comments about technical aspects and wording are all welcome.

When designing D libraries than lean towards DSL style, I've frequently felt impaired by the lack of implicit conversions in D. In my experience, it's not that all types need to be implicitly convertible to other types. Just being able to mark a few types as implicitly convertible to some other specific types would go a long way to alleviate the limitations I felt.  It would also solve problems like an arbitrary limit on the depth of implicit conversions.

I had imagined that maybe one day an implicit keyword could be introduced to mark such permissible implicit conversions. Seeing an implicit "keyword" being introduced here with different semantics than I envisioned makes me even less hopeful that some day such implicit conversions annotations could be introduced. So... maybe consider choosing some other syntactic notation? Besides, the fact that the compiler can implicitly introduce calls to the copy ctor doesn't strike me as something particularly central to the concept, so it seems like an odd choice for something to distinguish a copy ctor.

On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
> When designing D libraries than lean towards DSL style, I've frequently felt impaired by the lack of implicit conversions in D. In my experience, it's not that all types need to be implicitly convertible to other types. Just being able to mark a few types as implicitly convertible to some other specific types would go a long way to alleviate the limitations I felt.  It would also solve problems like an arbitrary limit on the depth of implicit conversions.
>
> I had imagined that maybe one day an implicit keyword could be introduced to mark such permissible implicit conversions. Seeing an implicit "keyword" being introduced here with different semantics than I envisioned makes me even less hopeful that some day such implicit conversions annotations could be introduced. So... maybe consider choosing some other syntactic notation? Besides, the fact that the compiler can implicitly introduce calls to the copy ctor doesn't strike me as something particularly central to the concept, so it seems like an odd choice for something to distinguish a copy ctor.

More details. The DIP says:

"The structName type needs to be identical to typeof(this); an error is issued otherwise. This requirement may be relaxed in the future in order to accomodate copying from objects of a different type"
(BTW, typo in "accomodate")

That would mean that if such a relaxation were introduced, then suddenly *all* copy ctors would imply implicit conversion between the respective types. Given D's stance on implicit conversions, I suspect that's not going to pass mustard. So I would prefer the any "implicit" keyword-like annotation to be reserved for explicitly approved implicit conversions.

On 12.07.2018 15:29, Andrei Alexandrescu wrote:
> On 07/11/2018 05:55 AM, Nick Treleaven wrote:
>> ...
>>
>> Removing `static` works. Otherwise I tried changing `ref` to `alias`:
>>
>> Error: variable src cannot be read at compile time
>>
>> But this shorter code seems to work fine:
>>
>> this.tupleof = src.tupleof;
> 
> Odd. Timon, what would be the reason for that error? Razvan, can you please look into removing "static" for now. Thanks!

The reason for this specific error is that `src.i` is neither a symbol nor a constant value. tupleof is a case of built-in compiler magic, because it can produce an expression tuple that contains run-time values that are not symbols. The following (manually unrolled) code also does not work:

alias field0 = s.tupleof[0];
t.tupleof[0] = field0;
alias field1 = s.tupleof[1];
t.tupleof[1] = field1;
alias field2 = s.tupleof[2];
t.tupleof[2] = field2;

Error: alias `a` cannot alias an expression `tuple(s.a, s.b, s.c)[0]`
Error: alias `b` cannot alias an expression `tuple(s.a, s.b, s.c)[1]`
Error: alias `c` cannot alias an expression `tuple(s.a, s.b, s.c)[2]`

It could be argued that the `static foreach` implementation should produce the same error message. (The fact that the AliasDecl constructor takes a Dsymbol instead of an Expression has led to multiple reimplementations of parts of the aliasing logic in different parts of the DMD code, `static foreach` is using the same implementation also used by unrolled foreach, and it requires that all loop variables are either symbols or constant values, while unrolled foreach can fall back to introducing runtime variables for this special case.)

One way to fix is to lift all the unnecessary limitations that are introduced by the fact that the AliasDecl constructor takes a Dsymbol. I.e. that "you can only alias symbols".

Alternatively, it would be possible to redefine `static foreach` statements such that they work for any aggregate with statically known length and element types, and to allow run-time loop variables to be generated when iterating over run-time values.

On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
> More details. The DIP says:
>
> "The structName type needs to be identical to typeof(this); an error is issued otherwise. This requirement may be relaxed in the future in order to accomodate copying from objects of a different type"
> (BTW, typo in "accomodate")
>
> That would mean that if such a relaxation were introduced, then suddenly *all* copy ctors would imply implicit conversion between the respective types. Given D's stance on implicit conversions, I suspect that's not going to pass mustard. So I would prefer the any "implicit" keyword-like annotation to be reserved for explicitly approved implicit conversions.

BTW: Multiple alias this is still planned for inclusion in D, right? If so, what would be the (pratical?) difference between having copy ctors with such a relaxed type requirement and just defining an equivalent alias this method? In case the answer is that there's no significant difference, why not drop multiple alias this, then?

On 12.07.2018 17:22, Timon Gehr wrote:
> 
> alias field0 = s.tupleof[0];
> t.tupleof[0] = field0;
> alias field1 = s.tupleof[1];
> t.tupleof[1] = field1;
> alias field2 = s.tupleof[2];
> t.tupleof[2] = field2;
> 
> Error: alias `a` cannot alias an expression `tuple(s.a, s.b, s.c)[0]`
> Error: alias `b` cannot alias an expression `tuple(s.a, s.b, s.c)[1]`
> Error: alias `c` cannot alias an expression `tuple(s.a, s.b, s.c)[2]`

The error messages are actually:

Error: alias `field0` cannot alias an expression `tuple(s.a, s.b, s.c)[0]`
Error: alias `field1` cannot alias an expression `tuple(s.a, s.b, s.c)[1]`
Error: alias `field2` cannot alias an expression `tuple(s.a, s.b, s.c)[2]`

On 07/12/2018 10:54 AM, Jonathan M Davis wrote:
> On Thursday, 12 July 2018 07:45:30 MDT Andrei Alexandrescu via Digitalmars-d
> wrote:
>>> I also very much dislike the syntax - it makes no sense to me at all. I
>>> commented on the PR itself asking why it differs so much from C++ -
>>> specifically, what's bad about the C++ way of doing things there that we
>>> want to avoid?
>>
>> C++ is at the other end of the spectrum - constructors are too implicit,
>> so the "explicit" keyword has been introduced with the advice to use it
>> in the vast majority of cases. If C++ could do it again, it would make
>> everything explicit and add an "implicit" keyword.
> 
> That's only an issue in C++, because C++ uses constructors for implicit
> conversions unless you mark them with explicit. D doesn't ever do implicit
> conversions like that. All constructors are effectively explicit. Is this
> DIP proposing that we add such implicit conversions?

The DIP is proposing what's in the DIP :o). We actually clarify this in text:

"The type of the parameter to the copy constructor needs to be identical to typeof(this); an error is issued otherwise. This requirement may be relaxed in the future in order to accomodate implicit copying from objects of a different type:" [example follows]

> I really don't understand what the purpose of @implicit is here. What's the
> problem of just going off of the type of the constructor's single parameter
> to determine whether it's a copy constructor?

That would silently change semantics of existing code, which is to be avoided.


Andrei

On Thursday, 12 July 2018 at 15:25:10 UTC, Luís Marques wrote:
> On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote:
> BTW: Multiple alias this is still planned for inclusion in D, right? If so, what would be the (pratical?) difference between having copy ctors with such a relaxed type requirement and just defining an equivalent alias this method? In case the answer is that there's no significant difference, why not drop multiple alias this, then?

Sorry for the stream-of-conscience type posts. But, to clarify further: if alias this provides access to the members of the converted type (besides type conversion), couldn't that feature be folded into the same mechanism of the copy ctor (or vice-versa), to avoid mostly redundant features in the language, with subtle interactions?

On 07/12/2018 11:14 AM, Luís Marques wrote:
> On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
>> When designing D libraries than lean towards DSL style, I've frequently felt impaired by the lack of implicit conversions in D. In my experience, it's not that all types need to be implicitly convertible to other types. Just being able to mark a few types as implicitly convertible to some other specific types would go a long way to alleviate the limitations I felt. It would also solve problems like an arbitrary limit on the depth of implicit conversions.
>>
>> I had imagined that maybe one day an implicit keyword could be introduced to mark such permissible implicit conversions. Seeing an implicit "keyword" being introduced here with different semantics than I envisioned makes me even less hopeful that some day such implicit conversions annotations could be introduced. So... maybe consider choosing some other syntactic notation? Besides, the fact that the compiler can implicitly introduce calls to the copy ctor doesn't strike me as something particularly central to the concept, so it seems like an odd choice for something to distinguish a copy ctor.
> 
> More details. The DIP says:
> 
> "The structName type needs to be identical to typeof(this); an error is issued otherwise. This requirement may be relaxed in the future in order to accomodate copying from objects of a different type"
> (BTW, typo in "accomodate")
> 
> That would mean that if such a relaxation were introduced, then suddenly *all* copy ctors would imply implicit conversion between the respective types.

No, only constructors annotated with @implicit would be implicit. But that's only a possible future direction not part of this DIP.

Also there are many complications related to allowing implicit conversions across distinct types, and this DIP should not get embroiled in those. That would be a different pursuit that I encourage you to consider.