http://wiki.dlang.org/DIP25

[Manu via Digitalmars-d]

On 3 January 2015 at 10:07, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 1/2/2015 2:38 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>>
>> On 02/01/15 22:16, Walter Bright via Digitalmars-d wrote:
>>>
>>> I don't believe it is impossible to implement in D, in fact, Bartosz
>>> Milewski
>>> proposed such a system some years back. I do believe that people will
>>> simply
>>> reject such a system as too hard to use.
>>
>>
>> Isn't that dependent on the use-case, though?  We know very well that
>> games
>> programmers (for example) will jump through programming fire, compared to
>> many
>> other developers, in order to achieve their desired results.
>
>
> Take a look at noted game developer Jonathan Blow's videos. They'll jump
> through hoops for performance, but I see little evidence they will do so for
> correctness. It's like have a nun stand over you and rap your knuckles every
> time your handwriting isn't perfect. Nobody likes that.

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!


>> Assuming that we're not going to lose the default case of the GC being
>> responsible for allocation/ownership unless the programmer specifies
>> otherwise,
>> what's wrong with having a rigorous ownership system in place that can be
>> made
>> use of if and only if the programmer sees value in it?
>
>
> 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.
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.

In practise, I suspect it would be more like pure or nothrow in its
impact. How many hours do you spend wrangling pure or nothrow issues
compared to const issues?
I can say that pure/nothrow barely ever cause me any trouble, and when
they do, I'm often surprised that they actually reveal what would have
been a bug.

An awful lot of the modern big-ticket problems in software engineering
are relating to ownership.


>> I hope it's obvious what I'm getting at here -- a really simple, general
>> and
>> powerful syntax can become horrendously complicated to deal with once you
>> start
>> going beyond a certain scale of combinations.
>
>
> Don't I know it :-)

We're already there though. And to resist one more with very
significant importance is drawing an arbitrary line. You got behind
@nogc fairly recently with no particular friction...
We already know we have to get better at attribute inference, that's
critical to addressing the situation we are already in. Assuming we
succeed with that (we must, and it's not a particularly hard problem
anyway), then that solution applies equally for this case too.

But if we have drawn a hard line in terms of quantity of attributes, I
would gladly sacrifice @nogc, or nothrow in favour of scope.