April 23, 2013
On 04/23/2013 10:16 AM, Dicebot wrote:
> On Wednesday, 10 April 2013 at 07:39:25 UTC, Zach the Mystic wrote:
>> ...
>
> Kind of. I am thinking that scope is best when transitive for
> aggregation but not for indirection:
>
> struct S { int a; int *b; }
>
> void foo(scope S s)
> {
>      static int *x1 = &(s.a); // error
>      static int *x2 = s.b; // fine
> }

(Both of these are in error because static variables are initialized at compile time, but I get what you mean.)

Why would 'scope' have any effect on the validity of the first? s.a belongs to the callee exclusively. Adding modular annotations to prevent taking its address has no point.
April 23, 2013
On Tuesday, 23 April 2013 at 08:25:18 UTC, Timon Gehr wrote:
> (Both of these are in error because static variables are initialized at compile time, but I get what you mean.)

Shame on me! (blush)

> Why would 'scope' have any effect on the validity of the first? s.a belongs to the callee exclusively. Adding modular annotations to prevent taking its address has no point.

Because it is an attempt to take/store address of a scope variable, which is prohibited by scope definition. I think (but I am not sure!) that it makes sense to make scope transitive for aggregation, because automatic destruction upon leaving the scope happens for aggregated entities. Thus, nothing can be known about s.a lifetime, same as s lifetime. This is one step towards consistent "scope" behavior that will allow safety desired by this DIP.
April 23, 2013
On Tuesday, 23 April 2013 at 08:19:43 UTC, Timon Gehr wrote:
> It is disallowed in @system code.

Ye, I know and always took it as yet another "we care mostly for @safe" issue. What is the real rationale for this restriction?
April 23, 2013
On 4/23/13 4:08 AM, Dicebot wrote:
> You consider "scope" a new language feature?

Yes.

> And consider "auto ref"
> improvable solution.

Yes.

> The very point of this DIP is to not create
> syntax-driven features, instead better define existing ones that make
> sense on their own so they can be used for same purpose.

It's a new feature, no two ways about it. It overlaps ref and auto ref without any palpable benefit and defines yet another way to achieve the same thing as auto ref. On this ground alone the proposal has a large problem.

>> 2. The proposal is sketchy and does not give many details, such as the
>> lifetime of temporaries bound to scope ref objects.
>
> It can't because lifetime of temporaries is not defined in D at all and
> suck stuff needs to be consistent. It is not really different from a
> lifetime of struct literal temporary used for pass-by-value.

A proposal aimed at binding rvalues to references must address lifetime of temporaries as a central concern.

>> 3. The relationship with auto ref is insufficiently described, e.g.
>> there should be clarification on why auto ref cannot be improved to
>> fulfill the desired role.
>
> auto ref is a template-world entity. If by "improved" you mean
> "completely reworked" than sure, I can add this rationale. Will do today.

I think we should focus on http://d.puremagic.com/issues/show_bug.cgi?id=9238 and on making ref safe.

>> 4. Above all this is a new language feature and again we want to
>> resort to adding new feature only if it is clear that the existing
>> features are insufficient and cannot be made sufficient. In particular
>> we are much more inclined to impart real, demonstrable safety to "ref"
>> and to make "auto ref" work as a reference that can bind to rvalues as
>> well as lvalues.
>
> Can't agree. "scope" is defined (but not implemented, a pity). Creating
> temporaries already exists for some cases. No really new language
> feature is added. No special syntax created. "scope ref" is still
> "scope" and "ref" with all semantics this imposes, rvalue references are
> just a side-effect. Contrary to this, "auto ref" IS a new feature
> created specifically for syntax hack. That is a very problem you are
> speaking about - introducing new concepts instead of making use of ones
> that exist for ages.

You are of course to disagree, but that would make you wrong.


Andrei
April 23, 2013
On Tuesday, 23 April 2013 at 14:24:06 UTC, Andrei Alexandrescu wrote:
> On 4/23/13 4:08 AM, Dicebot wrote:
>> You consider "scope" a new language feature?
>
> Yes.

Well, ok, that explains everything.
Thank you.
April 23, 2013
On 24 April 2013 00:24, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>wrote:

>
>> The very point of this DIP is to not create
>> syntax-driven features, instead better define existing ones that make
>> sense on their own so they can be used for same purpose.
>>
>
> It's a new feature, no two ways about it. It overlaps ref and auto ref without any palpable benefit and defines yet another way to achieve the same thing as auto ref. On this ground alone the proposal has a large problem.


How does it overlap ref? It simply justifies the argument with an extra constraint and isn't tied to 'ref' at all, it's just useful in conjunction.

I can't agree that it overlaps auto-ref at all. They're fundamentally
different concepts. auto-ref is a template concept; it selects the ref-ness
based on the received arg. 'auto ref', ie, 'automatic ref-ness'. It makes
no sense on a non-template situation.
I'm still completely amazed that the very reason this DIP makes perfect
sense to me(/us) is the same reason you have a problem with it.

 2. The proposal is sketchy and does not give many details, such as the
>>> lifetime of temporaries bound to scope ref objects.
>>>
>>
>> It can't because lifetime of temporaries is not defined in D at all and suck stuff needs to be consistent. It is not really different from a lifetime of struct literal temporary used for pass-by-value.
>>
>
> A proposal aimed at binding rvalues to references must address lifetime of temporaries as a central concern.


It's not an r-value, it's a standard stack-allocated temporary. It's
lifetime is identical to any other local.
The reason it's not detailed in the proposal is because it adds no such new
feature, and makes no changes. The lifetime of a local is well understood.


 3. The relationship with auto ref is insufficiently described, e.g.
>>> there should be clarification on why auto ref cannot be improved to fulfill the desired role.
>>>
>>
>> auto ref is a template-world entity. If by "improved" you mean "completely reworked" than sure, I can add this rationale. Will do today.
>>
>
> I think we should focus on http://d.puremagic.com/issues/**
> show_bug.cgi?id=9238 <http://d.puremagic.com/issues/show_bug.cgi?id=9238>and on making ref safe.


I don't believe it's possible to make ref safe. Can you suggest any vision
for this?
It's unsafe by definition... you are passing a pointer of unknown origin to
a function that could do anything with that pointer.
Hence 'scope ref', which appropriately restricts what the callee is able to
do with it.

 4. Above all this is a new language feature and again we want to
>>> resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to "ref" and to make "auto ref" work as a reference that can bind to rvalues as well as lvalues.
>>>
>>
>> Can't agree. "scope" is defined (but not implemented, a pity). Creating temporaries already exists for some cases. No really new language feature is added. No special syntax created. "scope ref" is still "scope" and "ref" with all semantics this imposes, rvalue references are just a side-effect. Contrary to this, "auto ref" IS a new feature created specifically for syntax hack. That is a very problem you are speaking about - introducing new concepts instead of making use of ones that exist for ages.
>>
>
> You are of course to disagree, but that would make you wrong.


Explain why? Proclaiming he is simply wrong when he presents sound reason isn't helpful.


April 23, 2013
On 4/23/13 12:04 PM, Manu wrote:
> On 24 April 2013 00:24, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>
>
>         The very point of this DIP is to not create
>         syntax-driven features, instead better define existing ones that
>         make
>         sense on their own so they can be used for same purpose.
>
>
>     It's a new feature, no two ways about it. It overlaps ref and auto
>     ref without any palpable benefit and defines yet another way to
>     achieve the same thing as auto ref. On this ground alone the
>     proposal has a large problem.
>
>
> How does it overlap ref? It simply justifies the argument with an extra
> constraint and isn't tied to 'ref' at all, it's just useful in conjunction.

The best setup would be:

1. To take lvalues by reference, write "ref".

2. To take lvalues and rvalues by reference, write "auto ref".

Everything else is superfluous and puts the burden of justification on the proposer. With DIP36, the setup would be:

1. To take lvalues by reference, write "ref".

2. To take lvalues and rvalues by reference:

2.1. Is it a template? Then write "auto ref".

2.2. Is it a non-template? Then write "scope ref".

> I can't agree that it overlaps auto-ref at all. They're fundamentally
> different concepts. auto-ref is a template concept; it selects the
> ref-ness based on the received arg. 'auto ref', ie, 'automatic
> ref-ness'. It makes no sense on a non-template situation.
> I'm still completely amazed that the very reason this DIP makes perfect
> sense to me(/us) is the same reason you have a problem with it.

I don't know how to respond to this. To me is it painfully obvious DIP 36 is poor language design and fails to solve a variety of issues, such as clarifying lifetime of temporaries, safety, and returning ref from functions.

>             2. The proposal is sketchy and does not give many details,
>             such as the
>             lifetime of temporaries bound to scope ref objects.
>
>
>         It can't because lifetime of temporaries is not defined in D at
>         all and
>         suck stuff needs to be consistent. It is not really different from a
>         lifetime of struct literal temporary used for pass-by-value.
>
>
>     A proposal aimed at binding rvalues to references must address
>     lifetime of temporaries as a central concern.
>
>
> It's not an r-value, it's a standard stack-allocated temporary. It's
> lifetime is identical to any other local.
> The reason it's not detailed in the proposal is because it adds no such
> new feature, and makes no changes. The lifetime of a local is well
> understood.

Currently rvalues are destroyed immediately after the call they are passed into. DIP 36 would need to change that, but fails to specify it.

>             3. The relationship with auto ref is insufficiently
>             described, e.g.
>             there should be clarification on why auto ref cannot be
>             improved to
>             fulfill the desired role.
>
>
>         auto ref is a template-world entity. If by "improved" you mean
>         "completely reworked" than sure, I can add this rationale. Will
>         do today.
>
>
>     I think we should focus on
>     http://d.puremagic.com/issues/__show_bug.cgi?id=9238
>     <http://d.puremagic.com/issues/show_bug.cgi?id=9238> and on making
>     ref safe.
>
>
> I don't believe it's possible to make ref safe. Can you suggest any
> vision for this?

http://d.puremagic.com/issues/show_bug.cgi?id=9238

> It's unsafe by definition... you are passing a pointer of unknown origin
> to a function that could do anything with that pointer.
> Hence 'scope ref', which appropriately restricts what the callee is able
> to do with it.

Our intent is to make "ref" always scoped and reserve non-scoped uses to pointers. We consider this good language design: we have unrestricted pointers for code that doesn't care much about safety, and we have "ref" which is almost as powerful but sacrifices a teeny bit of that power for the sake of guaranteed safety. Safety is guaranteed by making sure "ref" is always scoped (references can be passed down but never escape their bound value).

>             4. Above all this is a new language feature and again we want to
>             resort to adding new feature only if it is clear that the
>             existing
>             features are insufficient and cannot be made sufficient. In
>             particular
>             we are much more inclined to impart real, demonstrable
>             safety to "ref"
>             and to make "auto ref" work as a reference that can bind to
>             rvalues as
>             well as lvalues.
>
>
>         Can't agree. "scope" is defined (but not implemented, a pity).
>         Creating
>         temporaries already exists for some cases. No really new language
>         feature is added. No special syntax created. "scope ref" is still
>         "scope" and "ref" with all semantics this imposes, rvalue
>         references are
>         just a side-effect. Contrary to this, "auto ref" IS a new feature
>         created specifically for syntax hack. That is a very problem you are
>         speaking about - introducing new concepts instead of making use
>         of ones
>         that exist for ages.
>
>
>     You are of course to disagree, but that would make you wrong.
>
>
> Explain why? Proclaiming he is simply wrong when he presents sound
> reason isn't helpful.

I assumed it was obvious from what I'd already written. The claim has been made that "scope ref" is not a new language feature. I don't know how to reply to that other than, well, it is.


Andrei
April 23, 2013
On Tue, 23 Apr 2013 13:33:31 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Our intent is to make "ref" always scoped and reserve non-scoped uses to pointers.

So no more returning ref?  Because if you allow returning ref, you lose any notion of safety, unless you plan on changing the entire compilation model?

> We consider this good language design: we have unrestricted pointers for code that doesn't care much about safety, and we have "ref" which is almost as powerful but sacrifices a teeny bit of that power for the sake of guaranteed safety. Safety is guaranteed by making sure "ref" is always scoped (references can be passed down but never escape their bound value).

Not being able to return ref is a large loss of power.

Not arguing in favor of DIP36, but it seems there is a misunderstanding as to what it does.

-Steve
April 23, 2013
> So no more returning ref?  Because if you allow returning ref, you lose any notion of safety, unless you plan on changing the entire compilation model?

The rules from DIP25/35 show how you can return refs while still maintaining safety.
April 23, 2013
On 4/23/13 1:57 PM, Steven Schveighoffer wrote:
> On Tue, 23 Apr 2013 13:33:31 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Our intent is to make "ref" always scoped and reserve non-scoped uses
>> to pointers.
>
> So no more returning ref?

If we can't return ref, ref has failed. (This is what makes the entire thing difficult btw.)

Andrei