On 12/31/2014 07:17 AM, Manu via Digitalmars-d wrote:
> And even then, passing by value in not something you would do! Why
> would you ever pass some big struct by value?

Sure if it's an rvalue.

On 4 January 2015 at 10:38, Martin Nowak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 12/31/2014 07:17 AM, Manu via Digitalmars-d wrote:
>>
>> And even then, passing by value in not something you would do! Why would you ever pass some big struct by value?
>
> Sure if it's an rvalue.

Really?
Don't get me started...

On 3 January 2015 at 18:41, Walter Bright via Digitalmars-d <digitalmars-d@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?

On 1/3/2015 5:12 PM, Manu via Digitalmars-d wrote:
> Are you saying const was a mistake? Should we be trying to avoid using
> const? And use that as justification against in this case?

const to me suggested a limit on what we can do in pushing annotations on people. It is also quite simple in concept.


> 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?

It will pervade deeply if it was 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?

Bob Vila's flip answer, as if nobody thought of adding lights to better light up a dark room.

On 4 January 2015 at 13:34, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 1/3/2015 5:12 PM, Manu via Digitalmars-d wrote:
>
>> 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?
>
>
> It will pervade deeply if it was part of the type.

Right, and that's the entire point.
Are there problems with that, or just fear of the scope of the change?

I don't see how an effort to keep this confined within a small box
such that it doesn't pervade can ever result in orthogonal behaviour.
It's too important a concept, and it will appear everywhere, in all
kinds of situations. Much more than ref I'm sure.
Any time the concept finds itself bleeding outside it's little box,
the problems will be awkward and practically unmanageable.

On 1/3/2015 5:12 PM, Manu via Digitalmars-d wrote:
> 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?

I felt unaddressed what are the interactions with other scope qualifiers, how type deduction works, how would auto work, covariance, how are types like

   int****scope(foo)****

handled, how would generic code get written that used this, name mangling, auto returns, etc. A comprehensive spec for it would be much larger. I tried to do a more comprehensive spec with DIP69, and it wound giving the impression that it was more complex when it was actually simpler. I'm also painfully aware of how 'simple' C++'s ref appeared and how awful it is in practice.

And lastly, I thought it verbose, such as:

   scope!haystack(string) findSubstring(scope(string) haystack, scope(string) needle);

There have been many complaints, including from you, about the existing verbosity of function declarations.

On 03/01/15 15:42, Adam D. Ruppe via Digitalmars-d wrote:
> I've heard this a few times before over the years, and it hasn't happened yet.
> Perhaps we're not growing at the the necessary rapid rate, but I think new
> people try to blend into what they see other people doing, so as long as at any
> given time, the majority of us behave fairly well, it will stay that way.
>
> I agree with what you're saying about a fair process and I don't think some
> guidelines about how to deal with trouble would be bad, even if it is as simple
> as "please don't feed the trolls" or even "turn the other cheek"*. But I also
> think we're doing OK as it is right now and have been for a lot of years and
> probably will be for many years more.

I think that's fair enough.  Bear in mind that what I actually proposed was a guideline for one quite specific scenario, i.e. how to handle people asking for features, proposing ideas, and so on, who were not willing or able to step up and deliver them.

I'd be happy if that principle was simply accepted by core community members (it seems to have been) and promulgated by example and polite nudges.

> 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.
>

I thought most of your problems stem from 'auto ref' and not from ref? If scope does not affect the overload set, I don't see how you could get into trouble with meta programming using it. Could you please clarify?

On Monday, 29 December 2014 at 20:26:27 UTC, Steven Schveighoffer wrote:
> On 12/29/14 2:50 PM, Walter Bright wrote:
>> On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
>>> On 12/28/14 4:33 PM, Walter Bright wrote:
>>>> inout is not transitive, so a ref on the container doesn't apply to a
>>>> ref on the contents if there's another level of indirection in there.
>>> I'm not sure what you mean by this, but inout as a type modifier is
>>> definitely
>>> transitive.
>>
>> As a type modifier, yes, it is transitive. As transferring lifetime to
>> the return value, it is not.
>>
>
> I strongly suggest not to use inout to mean this. This idea would be a disaster.
>
> -Steve

On the other hand, inout IS a disaster, so why not ?

On Wednesday, 31 December 2014 at 21:08:29 UTC, Dicebot wrote:
> This mostly matches my current opinion of DIP25 + DIP69 as well. It is not as much problem of lacking power but utterly breaking KISS principle - too many special cases to remember, too many concepts to learn. Path of minimal necessary change is tempting but it is path to C++.

Yes especially when this path create non orthogonal features, which inevitably create a complexity explosion down the road.

This is the very old simple vs easy problem. Easy is tempting, but simple is what we want and they sometime are very different things.