12-Dec-2014 00:41, Walter Bright пишет:
> On 12/11/2014 4:47 AM, Manu via Digitalmars-d wrote:
>> On 8 December 2014 at 07:29, Walter Bright via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:

>> I don't have the perfect proposal, but I feel very strongly about 2
>> things:
>> 1. It must not be a storage class; the concept was a disaster with
>> ref, and I struggle with this more frequently than any other 'feature'
>> in D.
>
> I simply do not understand why distinguishing beteen ref and not-ref is
> a cornerstone of everything you do.
>

I would hazard a guess that const T& is something lots of C++ got addicted to as the most common way of parameter passing. There is nothing exactly like that in D, auto ref was quite close but only for templates and it instantiates 2 distinct bodies for ref and non-ref at the moment.

It allows easy pass by ref for both r-values and l-values with logical const and is likely what Manu is referring(!) to.

Truth be told it's not always the fastest way, in fact Boost C++ has template for optimal parameter passing - call_traits<T>::param_type  but it must be too cumbersome for actual use as I never seen it used in the wild.
http://www.boost.org/doc/libs/1_57_0/libs/utility/call_traits.htm

-- 
Dmitry Olshansky

On Thursday, 11 December 2014 at 21:41:11 UTC, Walter Bright wrote:
> On 12/11/2014 4:47 AM, Manu via Digitalmars-d wrote:
>> On 8 December 2014 at 07:29, Walter Bright via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:
>>> On 12/7/2014 6:12 AM, Dicebot wrote:
>>>>
>>>> But from existing cases it doesn't seem working good enough. For example,
>>>> not
>>>> being able to represent idiom of `scope ref int foo(scope ref int x) {
>>>> return x;
>>>> }` seems very limiting.
>>>
>>>
>>>   scope ref int foo(ref int x);
>>>
>>> will do it.
>>
>> Will it? It looks like foo can't be called with scope data?
>
> Yes, it can be.
>
>
>> I don't have the perfect proposal, but I feel very strongly about 2 things:
>> 1. It must not be a storage class; the concept was a disaster with
>> ref, and I struggle with this more frequently than any other 'feature'
>> in D.
>
> I simply do not understand why distinguishing beteen ref and not-ref is a cornerstone of everything you do.

Because he requires control over function ABIs for both inter-language communication and performance.

In binding D to IDL (Interactive Data, not Interface Description) I found ref often required special casing.

On Thursday, 11 December 2014 at 09:07:44 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 11 December 2014 at 00:35:46 UTC, deadalnix wrote:
>> It is always safe to consider scopeness of the retrun value (if marked scope) as being the intersection of the lifetime of parameters.
>>
>> That should cover most bases, and we can still extends later if this is too limited (I suspect it is ok for most cases).
>
> Linear typing is already extremely limiting, by limiting it even further you end up with something annoying. You basically get a version of memory safety that does not solve any typical memory unsafe situations.
>
> By having pointers that do scope-depth-tracking you do at least get a generic solution that can be optimized away when possible. The D authors have to accept that you need to embed ownership in pointers if you want memory safety and convenience, or that you have to provide means to guide the semantic analysis. You need one or the other, or both, but you cannot pretend that you can do without.
>
> Arbitrary constraints are annoying, not convenient. If I as a programmer know that something is safe, then the compiler should accept it, and the language should allow me express it.

I have no idea what you are saying. It sounds like randomly generated gibberish.

On Thursday, 11 December 2014 at 13:55:55 UTC, Marc Schütz wrote:
> On Thursday, 11 December 2014 at 12:48:05 UTC, Manu via Digitalmars-d wrote:
>> On 8 December 2014 at 07:29, Walter Bright via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:
>>> On 12/7/2014 6:12 AM, Dicebot wrote:
>>>>
>>>> But from existing cases it doesn't seem working good enough. For example,
>>>> not
>>>> being able to represent idiom of `scope ref int foo(scope ref int x) {
>>>> return x;
>>>> }` seems very limiting.
>>>
>>>
>>>  scope ref int foo(ref int x);
>>>
>>> will do it.
>>
>> Will it? It looks like foo can't be called with scope data?
>
> This is a point that most people don't seem to understand yet, and which wasn't obvious for me either, at the beginning:
>
> * A `ref` parameter means that it cannot escape the function, _except_ by return.
> * A `scope ref` parameter means that it cannot escape the function  _ever_, not even by return.
> * A `scope ref` return means that it cannot leave the current statement.
>
> Therefore, a `scope ref` return value can be passed on to the next function as a `ref` argument. If that function again returns a reference (even if not explicitly designated as `scope`), the compiler will treat it as if it were `scope ref`.
>

No, it understood. It is simply not useful.

> I agree, this is important. In my proposal, this works without transitivity. The wrapper stores the pointer as a `scope` member, then by copying the wrapper, the pointer gets copied implicitly, to which the normal scope restrictions apply (`scope` on members means "will not outlive the aggregate"). If it stored it as normal non-scope pointer, it couldn't get assigned in the first place.

Wut ? You cante store anything with grear lifetime, including non scope things (as they'll have infinite lifetime). Meaning the only thing you know, is that thing are possibly scoped.

Meaning you have to assume infinite lifetime with every indirection, which make this proposal useless.

On Thursday, 11 December 2014 at 14:12:16 UTC, Nick Treleaven wrote:
> On 09/12/2014 16:25, Steven Schveighoffer wrote:
>> Will ref just automatically bind to any scoped reference?
>
> A ref parameter essentially is a scope ref parameter, but it can also be returned:
> http://forum.dlang.org/post/m64v3g$2bga$1@digitalmars.com

Introducing a keyword to be able to add arbitrary restriction that do not make the code safer, more optimization or anything is not paying for itself.

On Thursday, 11 December 2014 at 15:37:27 UTC, bearophile wrote:
> Nick Treleaven:
>
>> Sometimes innovative workarounds are developed that are difficult to foresee in advance - e.g. in Rust their type system can be restrictive, but they rely on trusted library functions/types to make more things possible in a safe way.
>
> Ideally a type system should be flexible enough, in practice giving it a high flexibility has significant costs (in compilation times, amount of code that implements the system, bugs in such implementation, costs for the final programmer in inventing a way to express the semantics, etc), so most languages avoid a too much complex type system (even Haskell does this) and accept reasonable workarounds...
>
> Bye,
> bearophile

What is important is how much expressiveness you get from the complexity. here we get almost none. Considering complexity alone is not going to yield good results.

On Thursday, 11 December 2014 at 08:30:55 UTC, Walter Bright wrote:
> On 12/10/2014 10:43 PM, Dicebot wrote:
>> On Thursday, 11 December 2014 at 03:30:07 UTC, Walter Bright wrote:
>>> If you want data to 'escape' from r.front, then it shouldn't be marked as
>>> scope. Definitely, using scope successfully will require some rethinking of
>>> how code is written.
>>
>> Allowing or prohibiting escaping of r.front in that example depends on
>> definition of mapped range. There is nothing to "rethink" about it - case is
>> almost identical to const+inout.
>
> One reason why with templates, they'll do scope inference.

So the answer really is "current proposal does not support it"? Well this alone seems limiting enough for me to kills the whole DIP. "Use templates everywhere" is not really an answer, we could as well just prohibit separate compilation without .di files and enjoy full source availability as inherent requirement.

On Thursday, 11 December 2014 at 21:41:11 UTC, Walter Bright wrote:
> Consider a ref counted type, RC!T. If scope were transitive, then you could not have, say, a tree where the edges were RC!T. I.e., the payload of an RC type should not be forced to be scope.

I don't see how this is related. It would be perfectly ok to declare root of such tree scope if it was transitive (as long as it only controls access and does not attempt early destruction).

You may want to explain this in details in DIP if this is motivating case.

On Friday, 12 December 2014 at 00:13:10 UTC, deadalnix wrote:
>> Therefore, a `scope ref` return value can be passed on to the next function as a `ref` argument. If that function again returns a reference (even if not explicitly designated as `scope`), the compiler will treat it as if it were `scope ref`.
>>
>
> No, it understood. It is simply not useful.

So far I tend to agree, unfortunately. Considering all provided answers and explanations suggested semantics are simply not powerful enough to be useful even for relatively simple idiomatic D code and with no clear way of backward compatible improvements this DIP does not pull own weight.

"Those are not scopes you are looking for"

On 12/11/2014 10:04 PM, Dicebot wrote:
> On Thursday, 11 December 2014 at 08:30:55 UTC, Walter Bright wrote:
>> On 12/10/2014 10:43 PM, Dicebot wrote:
>>> On Thursday, 11 December 2014 at 03:30:07 UTC, Walter Bright wrote:
>>>> If you want data to 'escape' from r.front, then it shouldn't be marked as
>>>> scope. Definitely, using scope successfully will require some rethinking of
>>>> how code is written.
>>>
>>> Allowing or prohibiting escaping of r.front in that example depends on
>>> definition of mapped range. There is nothing to "rethink" about it - case is
>>> almost identical to const+inout.
>>
>> One reason why with templates, they'll do scope inference.
>
> So the answer really is "current proposal does not support it"? Well this alone
> seems limiting enough for me to kills the whole DIP. "Use templates everywhere"
> is not really an answer, we could as well just prohibit separate compilation
> without .di files and enjoy full source availability as inherent requirement.

When you're relying on the definition of an argument, it is inherently a template.