On 9/12/2014 6:48 PM, Manu via Digitalmars-d wrote:
> What happens when a scope() thing finds it's way into generic code? If the type
> doesn't carry that information, then you end up in a situation like ref. Have
> you ever had to wrestle with ref in generic code?
> ref is the biggest disaster zone in D, and I think all it's problems will
> translate straight to scope if you do this.

I'm unaware of this disaster zone.

On Sunday, 21 September 2014 at 03:48:36 UTC, Walter Bright wrote:
> On 9/12/2014 6:48 PM, Manu via Digitalmars-d wrote:
>> What happens when a scope() thing finds it's way into generic code? If the type
>> doesn't carry that information, then you end up in a situation like ref. Have
>> you ever had to wrestle with ref in generic code?
>> ref is the biggest disaster zone in D, and I think all it's problems will
>> translate straight to scope if you do this.
>
> I'm unaware of this disaster zone.

Well it is very real. I had to duplicate bunch of code in my visitor generator recently because of it. Getting generic code ref correct is very tedious, error prone, and guarantees code duplication and/or various static ifs all over the place.

On 2014-09-21 05:38, Walter Bright wrote:

> 2. I think there is quite a bit of overlap between scope and ref.
> Essentially, ref does everything scope does, except deal with classes.
> I'm not terribly comfortable with such a large overlap, it implies
> something is wrong. I don't have an answer at the moment.

Am I missing something but isn't "ref" for passing something by reference instead of by value. "scope", in this proposal, is for dealing with lifetime? Or do you have any other proposal for what "ref" might become?

-- 
/Jacob Carlborg

On 9/21/2014 1:25 AM, Jacob Carlborg wrote:
> Am I missing something but isn't "ref" for passing something by reference
> instead of by value. "scope", in this proposal, is for dealing with lifetime? Or
> do you have any other proposal for what "ref" might become?

See this discussion:

http://www.digitalmars.com/d/archives/digitalmars/D/borrowed_pointers_vs_ref_232090.html

On Sunday, 21 September 2014 at 03:39:24 UTC, Walter Bright wrote:
> I think it's a well thought out proposal. Thanks for doing this!
>
> A couple thoughts:
>
> 1. const can be both a storage class and a type constructor. Scope is only a storage class. The scope(int) syntax implies scope is a type constructor, too.
>
>     const int* a;  // const used as storage class
>     const(int*) b; // const used as type constructor
>
> The type constructor syntax should be disallowed for const.

(... disallowed for _scope_, I assume)

I originally intended it to be part of the type. Ivan Timokhin pointed out severe problems with that [1], so I removed it from the proposal. The syntax is a remainder of that.

But before I remove it too, I have a question: Will it still be possible to use the storage class syntax for members of aggregates?

    struct S {
        scope!myAllocator int* p;
    }

>
> 2. I think there is quite a bit of overlap between scope and ref. Essentially, ref does everything scope does, except deal with classes. I'm not terribly comfortable with such a large overlap, it implies something is wrong. I don't have an answer at the moment.


I also see the overlap, but there are also large differences to the point that I cannot see how the two concepts could be unified. For one, `ref` with classes (and reference types in general) is troublesome, and would introduce a double indirection for borrowing, when a simple copy of the reference would be sufficient. Then, `scope` could also for non-reference types. File handles come to mind, which are often integers, and just need to be copied.

[1] http://forum.dlang.org/thread/etjuormplgfbomwdrurp@forum.dlang.org?page=3#post-lusirm:2421d9:241:40digitalmars.com

On Monday, 25 August 2014 at 11:48:18 UTC, Marc Schütz wrote:
> It would be desired in `chooseStringAtRandom`, but not in the `findSubstring`, whose returned string shouldn't be limited by the scope of the needle. If it is made the default, there would need to be a way to opt out, such as removing an owner.

If `in` will be defined as scope!callee, i.e. can't be returned, then it can be removed from the return type.

On 21 September 2014 16:02, deadalnix via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Sunday, 21 September 2014 at 03:48:36 UTC, Walter Bright wrote:
>
>> On 9/12/2014 6:48 PM, Manu via Digitalmars-d wrote:
>>
>>> What happens when a scope() thing finds it's way into generic code? If
>>> the type
>>> doesn't carry that information, then you end up in a situation like ref.
>>> Have
>>> you ever had to wrestle with ref in generic code?
>>> ref is the biggest disaster zone in D, and I think all it's problems will
>>> translate straight to scope if you do this.
>>>
>>
>> I'm unaware of this disaster zone.
>>
>
> Well it is very real. I had to duplicate bunch of code in my visitor generator recently because of it. Getting generic code ref correct is very tedious, error prone, and guarantees code duplication and/or various static ifs all over the place.
>

It's also extremely hard to unittest; explodes the number of static if paths exponentially. I'm constantly finding bugs appear a year after writing some code because I missed some static branch paths when originally authoring.

On 9/21/14, 4:27 AM, Manu via Digitalmars-d wrote:
> On 21 September 2014 16:02, deadalnix via Digitalmars-d
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>
>     On Sunday, 21 September 2014 at 03:48:36 UTC, Walter Bright wrote:
>
>         On 9/12/2014 6:48 PM, Manu via Digitalmars-d wrote:
>
>             What happens when a scope() thing finds it's way into
>             generic code? If the type
>             doesn't carry that information, then you end up in a
>             situation like ref.. Have
>             you ever had to wrestle with ref in generic code?
>             ref is the biggest disaster zone in D, and I think all it's
>             problems will
>             translate straight to scope if you do this.
>
>
>         I'm unaware of this disaster zone.
>
>
>     Well it is very real. I had to duplicate bunch of code in my visitor
>     generator recently because of it. Getting generic code ref correct
>     is very tedious, error prone, and guarantees code duplication and/or
>     various static ifs all over the place.
>
>
> It's also extremely hard to unittest; explodes the number of static if
> paths exponentially.. I'm constantly finding bugs appear a year after
> writing some code because I missed some static branch paths when
> originally authoring.

Is this because of problems with ref's definition, or a natural consequence of supporting ref parameters? -- Andrei

On Sunday, 21 September 2014 at 15:10:23 UTC, Andrei Alexandrescu wrote:
> Is this because of problems with ref's definition, or a natural consequence of supporting ref parameters? -- Andrei

There is various reason why this is complex:
 - classes must often be handled specifically.
 - auto ref is not very controllable and tend to end up with an combinatorial explosion of special cases.
 - it is complex to find out if something is ref or not in generic code.
 - it is not possible to conditionally declare something as ref. It is true of other qualifiers, but ref change the semantic in a more deeper way than, say, dropping pure or @safe.
 - you may want to use ref for very different semantics, which lead to different policies about what should be ref or not. There is no other way to implement these policies than spaghetti static if with meatball code duplication.

On 9/21/2014 4:27 AM, Manu via Digitalmars-d wrote:
> It's also extremely hard to unittest; explodes the number of static if paths
> exponentially. I'm constantly finding bugs appear a year after writing some code
> because I missed some static branch paths when originally authoring.

If you throw -cov while running unittests, it'll give you a report on which code was executed and which wasn't. Very simple and useful.