On 10 April 2013 21:36, deadalnix <deadalnix@gmail.com> wrote:

> On Tuesday, 9 April 2013 at 17:06:47 UTC, Namespace wrote:
>
>> http://wiki.dlang.org/DIP36
>>
>
> I see no point in adding that much complexity for something that can mostly be automated.
>

Where's the complexity? I find it intuitive and super useful.
I personally see this DIP as just fleshing out the functionality of scope
that I imagined/assumed from the moment I learned about the scope keyword.
I was actually quite surprised to learn it wasn't already like this :)

On Wednesday, 10 April 2013 at 11:37:43 UTC, Dicebot wrote:
> On Wednesday, 10 April 2013 at 11:36:22 UTC, deadalnix wrote:
>> On Tuesday, 9 April 2013 at 17:06:47 UTC, Namespace wrote:
>>> http://wiki.dlang.org/DIP36
>>
>> I see no point in adding that much complexity for something that can mostly be automated.
>
> Can you explain this a bit more extensively, probably with some sort of counter-proposal? I can't see where complexity comes from, this DIP introduces literally zero special cases.

I think he means that the Compiler could/should decide, if something should passed by ref or by value. But I think that would be far more complex than scope ref/in ref.

On 10 April 2013 22:27, Namespace <rswhite4@googlemail.com> wrote:

> On Wednesday, 10 April 2013 at 11:37:43 UTC, Dicebot wrote:
>
>> On Wednesday, 10 April 2013 at 11:36:22 UTC, deadalnix wrote:
>>
>>> On Tuesday, 9 April 2013 at 17:06:47 UTC, Namespace wrote:
>>>
>>>> http://wiki.dlang.org/DIP36
>>>>
>>>
>>> I see no point in adding that much complexity for something that can mostly be automated.
>>>
>>
>> Can you explain this a bit more extensively, probably with some sort of counter-proposal? I can't see where complexity comes from, this DIP introduces literally zero special cases.
>>
>
> I think he means that the Compiler could/should decide, if something should passed by ref or by value. But I think that would be far more complex than scope ref/in ref.
>

Right. Yeah, seems more complex for sure. It's also unreliable/unpredictable. Same as with the pure conversation, I really prefer explicit control of things to at least be an option. I really don't want to be guessing about things that I may be depending on.

I hope this proposal gets implemented soon :)

On Wednesday, 10 April 2013 at 12:40:57 UTC, Manu wrote:
> On 10 April 2013 22:27, Namespace <rswhite4@googlemail.com> wrote:
>
>> On Wednesday, 10 April 2013 at 11:37:43 UTC, Dicebot wrote:
>>
>>> On Wednesday, 10 April 2013 at 11:36:22 UTC, deadalnix wrote:
>>>
>>>> On Tuesday, 9 April 2013 at 17:06:47 UTC, Namespace wrote:
>>>>
>>>>> http://wiki.dlang.org/DIP36
>>>>>
>>>>
>>>> I see no point in adding that much complexity for something that can
>>>> mostly be automated.
>>>>
>>>
>>> Can you explain this a bit more extensively, probably with some sort of
>>> counter-proposal? I can't see where complexity comes from, this DIP
>>> introduces literally zero special cases.
>>>
>>
>> I think he means that the Compiler could/should decide, if something
>> should passed by ref or by value. But I think that would be far more
>> complex than scope ref/in ref.
>>
>
> Right. Yeah, seems more complex for sure. It's also
> unreliable/unpredictable. Same as with the pure conversation, I really
> prefer explicit control of things to at least be an option. I really don't
> want to be guessing about things that I may be depending on.

It is certainly more complex on the compiler implementation side. But the ends result can be much better, and any program would benefit from it.

Plus, do you know that depending on the ABI, some pass by value are already transformed as pass by ref ? This is already in place in some cases, and have been proven to work well.

Back to the DIP, it fail to define how and where lvalue are implicitely created, what are their lifetime, etc . . .

Finally, ref and scope would benefit much more from the introduction of lifetime into D than hacking around.

On Wednesday, 10 April 2013 at 13:51:59 UTC, deadalnix wrote:
> It is certainly more complex on the compiler implementation side. But the ends result can be much better, and any program would benefit from it.
>
> Plus, do you know that depending on the ABI, some pass by value are already transformed as pass by ref ? This is already in place in some cases, and have been proven to work well.
>
> Back to the DIP, it fail to define how and where lvalue are implicitely created, what are their lifetime, etc . . .
>
> Finally, ref and scope would benefit much more from the introduction of lifetime into D than hacking around.

DIP36 was intentionally tweaked in such way so that compiler is free to do any implementation and swap pass by values with pass by ref if needed - until it preserves the semantics guarantees.

Introduction of lifetime is very beneficial but not really relevant to _this_ DIP. If lifetime is well defined, idea of making struct literal lvalues may be discussed, but that is a different story.

I don't care about how complex compiler implementation is but behavior needs to be predictable by programmer, no observable magic. Scope happens to have exactly the semantics needed to make stuff work right here and right now, with no relation to possible improvements of ref and rvalue/lvalue system.

On Wednesday, 10 April 2013 at 09:31:22 UTC, Dicebot wrote:
>>> Safety of "ref" is not problem that this DIP tries to solve. It should be solved with DIP25. Now ref is not safe (despite the fact it pretends to) and it still won't be after DIP36 approval, not until issue is addressed in DIP25.
>>>
>>> No need to mix it.
>>
>> My proposed DIP35 uses 'scope' to enhance DIP25. I don't believe DIP25 is really complete. 'scope' would help it a lot, but that would give more meanings to 'scope' which are potentially in conflict with it just meaning rvalue temp.
>
> And how it is relevant to DIP36? It solves specific issue. It provides some hints how other DIP may use new opportunities. It is up to DIP25 and DIP35 to be built on top if this gets accepted first. Or other way around.
>
> DIPs are built in context for current language implementation, not some potential other DIPs.

I would say, if you are going to use a keyword ('scope' in this case) to mean something, and there are other uses of the keyword which are also useful, you have to decide first if there is a conflict, and second how it should be resolved. In my opinion there is a conflict. The only existing definition of 'scope' parameters we have suggets that it means the parameter may not be escaped. It turns out that such a parameter is possibly necessary to successfully seal references in D. If a different proposal wants to use the word to mean something else, then it's important to decide either that two different features require two different parameter attributes (DIP36 understands this, and proposes several alternate possibilities to use), or that each feature can always automatically include the other feature without any problems (possible but see my other responses), or that only one feature is truly important enough to be included in the language, allowing you to disregard the other feature entirely.

On Wednesday, 10 April 2013 at 07:43:57 UTC, Dicebot wrote:
> ...

Kenji, got any comments/objections on this point of view? It is not that late to change it back ;)

I think 'scope ref' should always pass the address of given argument to the function body. Because 'ref' always means "pass the address of given argument". So, if given argument is an rvalue, compiler will allocate a temporary on stack, save the rvalue in it, and take its address. If argument is an lvalue, take its address directly. It should be always true, eve if the parameter type is small int.

Essentially language semantics should not reflect low level implementation detail. After DIP36 is accepted, we will get a full set of tools for efficiency - T, ref T, and scope ref T. From the toolbox, you can choose the most efficient storage class based on the T.

void foo(MostEfficientParameters!(int, string, S, int[1024]) params) { ... }

Kenji Hara

2013/4/11 Dicebot <m.strashun@gmail.com>

> On Wednesday, 10 April 2013 at 07:43:57 UTC, Dicebot wrote:
>
>> ...
>>
>
> Kenji, got any comments/objections on this point of view? It is not that late to change it back ;)
>

You don't think exposing creation of temporaries is low level implementation
detail?

On Thursday, 11 April 2013 at 08:14:00 UTC, kenji hara wrote:
> ...
>
> Kenji Hara