http://wiki.dlang.org/DIP25

[Manu via Digitalmars-d]

On 3 January 2015 at 18:41, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 1/2/2015 9:27 PM, Manu via Digitalmars-d wrote:
>>
>> I feel like your resistance of comprehensive scope is some part
>> emotional, some part anecdotal... but little or not parts
>> experimentally based.
>> You appear to 'fear' what it would do... and maybe you have the
>> experience to judge that better than me, but I just can't see it!
>
>
> Hardly anyone understood DIP69, and that one is very simple compared to a
> comprehensive ownership system.

I didn't understand it because the approach didn't make sense to me.
It appeared to exhibit a whole lot of edge cases, and addressed
relatively few of the cases I care about.
The fact that it seemed so problematic lead me to presume that I
simply didn't understand it, rather than that it was actually as
problematic as it appeared.

Marc's proposal on the other hand made perfect sense to me. I don't
think anybody misunderstood Marc's proposal... why is that?


>>> Because of the viral nature of it, you cannot avoid it. It's like trying
>>> to
>>> avoid using const.
>>
>> scope isn't like const though, it's a different thing. I think you're
>> just trying to incite FUD with that particular comparison.
>> It doesn't inhibit interoperation of data the same way as const does.
>> It only inhibits interoperation in the case of escaping local data to
>> the outside world.
>
>
> That's a lot of handwaving.

That's my point!

Are you saying const was a mistake? Should we be trying to avoid using
const? And use that as justification against in this case?


>> Cases where we currently allow that (because the tech we have is
>> insufficient to detect the cases) are probably bugs. They violate D's
>> safety guarantees, and that's a core commitment of D.
>> I don't think we can ever really make good on the @safe commitment
>> without scope/lifetime. So from that perspective, we either need to
>> take scope seriously, or stop advertising that we take safety
>> seriously.
>
>
> DIP25 and 69 make it safe.

Perhaps, and they might address a problem here, but they just compound
the other problems in the language that I'm already the most critical
of.

I have come to oppose storage class absolutely. It has taken me half a
decade to get there, so don't tell me I didn't try to love it (I
really thought it was a good idea at first!).
The problem is, it doesn't fit in D. I can't support any further
commitment to that failed design.
storage class == frustration, text mixins, and code duplication. Those
are really bad things.

I'm more frustrated by storage class than I am about echoing an rvalue
to a stupidly named temporary on the stack so I can pass it to a
function (which I am also extremely frustrated with).
I really need a good RC implementation, but I don't think we should be
making this sort of compromise for it.
Microsoft's C++/CX approach of "int ^rcPointer;" looks really elegant
to me by contrast.

It's like this: ref is a massive problem when it finds it's way into meta.
ref is relatively rare today... so the problem is occasional.
scope on the other hand will be epic compared to ref. If we infer
scope (which we'll probably need to), chances are, the vast majority
of functions will involve scope.
We can't have the trouble with ref (read: trouble with 'storage
class') applied to the majority of functions.


>> We're already there though. And to resist one more with very
>> significant importance is drawing an arbitrary line.
>
>
> Propose a design. I suggest, though, that if it was half as easy as you say,
> it would already exist in multiple languages. It's not like nobody thought
> of it before.

It's a relatively new hot-topic problem, and it exists in Rust; it's
basically the whole point of the language as far as I can tell.
Also, most modern languages aren't strongly typed, so it's an
irrelevant problem for most.

I was firmly in support of Marc's design. I'm not sure why it was rejected.
What were the problems? Why did it become a storage class, other than
because of fear that it might pervade too deeply if it were part of
the type?


> "Maybe some track lighting will help!"
>
>   --
> https://www.youtube.com/watch?feature=player_detailpage&v=P9FHlhWqbus#t=17

Umm, I don't understand?