On 07/12/2018 11:22 AM, Timon Gehr wrote:
> 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.

Thanks!

On 07/12/2018 11:25 AM, Luís Marques wrote:
> 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?

Again: not the charter of this DIP, so you should ask yourself, not us, this question.

On 07/12/2018 11:29 AM, Luís Marques wrote:
> 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?

The DIP mentions the interaction of @implicit with alias this.

On Thursday, 12 July 2018 at 15:34:25 UTC, Andrei Alexandrescu wrote:
> The DIP mentions the interaction of @implicit with alias this.

Not the interaction I was asking about, although admittedly it was speculative.

On Thursday, 12 July 2018 at 15:33:03 UTC, Andrei Alexandrescu wrote:
> Again: not the charter of this DIP, so you should ask yourself, not us, this question.

Look, I understand it can be frustrating to have a concrete design proposal derailed by a myriad of speculative questions. But if we suspect that design decision of a DIP might interact poorly with other plausible future D features, should we not at least express our concerns and hopes? By the time the other DIPs come out it might be too late to address the concerns.

In any case, I hope my comments were not too out of bounds of the discussion. If so, I'm sorry.

On Thursday, 12 July 2018 at 15:42:29 UTC, Luís Marques wrote:
> On Thursday, 12 July 2018 at 15:33:03 UTC, Andrei Alexandrescu wrote:
>> Again: not the charter of this DIP, so you should ask yourself, not us, this question.
>
> Look, I understand it can be frustrating to have a concrete design proposal derailed by a myriad of speculative questions. But if we suspect that design decision of a DIP might interact poorly with other plausible future D features, should we not at least express our concerns and hopes? By the time the other DIPs come out it might be too late to address the concerns.
>
> In any case, I hope my comments were not too out of bounds of the discussion. If so, I'm sorry.

I like the idea of implicit conversions (until I've been convinced otherwise at least), but I don't necessarily think this DIP will interact poorly with it. They could be implemented with a new opImplicitCast. Less elegantly, you could have special behavior when @implicit is used with opCast.

On 7/12/18 11:42 AM, Luís Marques wrote:
> On Thursday, 12 July 2018 at 15:33:03 UTC, Andrei Alexandrescu wrote:
>> Again: not the charter of this DIP, so you should ask yourself, not us, this question.
> 
> Look, I understand it can be frustrating to have a concrete design proposal derailed by a myriad of speculative questions. But if we suspect that design decision of a DIP might interact poorly with other plausible future D features, should we not at least express our concerns and hopes? By the time the other DIPs come out it might be too late to address the concerns.
> 
> In any case, I hope my comments were not too out of bounds of the discussion. If so, I'm sorry.

Definitely good topics to discuss. This is a collaborative process, not a confrontational one. If this DIP precludes good future decisions, that's definitely a meaningful discussion.

Am Thu, 12 Jul 2018 09:48:37 -0400 schrieb Andrei Alexandrescu:

>> I agree that the current syntax is lacking. This was Andrei's proposition and I was initially against it, but he said to put it in the DIP so that we can discuss it as a community. Maybe this syntax is better:
>> 
>> @this(ref S a another)
>> 
>> It looks like the c++ copy constructor but the `@` makes it different from a constructor, so we're good. What do you think?
> 
> We will not add syntax if we can help it.

We have this(this) for postblits so how about this(ref this a) for copy constructors?

Unfortunately this is currently valid code and compiles: this is treated as typeof(this). However, we have already deprecated that, so maybe we can reuse the syntax? It should be a quite consistent evolution from this(this).

(Another option is this(ref this A a) which does not conflict with existing syntax).

-- 
Johannes

Am Thu, 12 Jul 2018 17:32:06 +0000 schrieb Johannes Pfau:

> Am Thu, 12 Jul 2018 09:48:37 -0400 schrieb Andrei Alexandrescu:
> 
>>> I agree that the current syntax is lacking. This was Andrei's proposition and I was initially against it, but he said to put it in the DIP so that we can discuss it as a community. Maybe this syntax is better:
>>> 
>>> @this(ref S a another)
>>> 
>>> It looks like the c++ copy constructor but the `@` makes it different from a constructor, so we're good. What do you think?
>> 
>> We will not add syntax if we can help it.
> 
> We have this(this) for postblits so how about this(ref this a) for copy
> constructors?
> 
> Unfortunately this is currently valid code and compiles: this is treated as typeof(this). However, we have already deprecated that, so maybe we can reuse the syntax? It should be a quite consistent evolution from this(this).
> 
> (Another option is this(ref this A a) which does not conflict with
> existing syntax).

I just read your other replies Andrei. I guess if we're ever going use the same syntax for implicit conversions, the @implicit syntax is indeed consistent and logical. As long as it's only used for copy-ctors the name feels 'strange'.

-- 
Johannes

On 07/12/2018 03:40 PM, Andrei Alexandrescu wrote:
> On 07/10/2018 04:58 PM, Manu wrote:
[...]
>> 1. Explain the need and reasoning behind `@implicit`.
> 
> Razvan: I think it would help to explain that the attribute is necessary to avoid changing semantics of existing code. Thanks.

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.