On 12/8/2014 2:43 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> On Monday, 8 December 2014 at 10:34:42 UTC, Walter Bright wrote:
>> On 12/8/2014 1:52 AM, deadalnix wrote:
>>> On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
>>>> I thought I could make this work, but it's a problem. There are two meanings
>>>> for scope when attached to a function:
>>>>
>>>>    T func() scope;   // the 'this' pointer is 'scope'
>>>>    scope T func();   // the function returns a 'scope' T
>>>>
>>>> I have some ideas, but don't particularly like any of them. But I don't want
>>>> to bias things, so what ideas do you guys have?
>>>
>>> I'm arguing for ages that qualifier before the return type qualify the return
>>> type, and the one after the implicit argument. I stand by this.
>>
>> The trouble with that is, for example, __traits(getFuncAttributes, ...) which
>> will return "scope" for both cases.
>
> Why would it? A qualifier/stc for the implicit `this` parameter is not a
> function attribute.

That's a good point, but it currently returns 'ref' returns as an attribute.

On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
> I thought I could make this work, but it's a problem. There are two meanings for scope when attached to a function:
>
>     T func() scope;   // the 'this' pointer is 'scope'
>     scope T func();   // the function returns a 'scope' T
>
> I have some ideas, but don't particularly like any of them. But I don't want to bias things, so what ideas do you guys have?

You could make the 2nd an error and insist on it being written scope(T)

On Monday, 8 December 2014 at 09:52:02 UTC, deadalnix wrote:
> On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
>> I thought I could make this work, but it's a problem. There are two meanings for scope when attached to a function:
>>
>>    T func() scope;   // the 'this' pointer is 'scope'
>>    scope T func();   // the function returns a 'scope' T
>>
>> I have some ideas, but don't particularly like any of them. But I don't want to bias things, so what ideas do you guys have?
>
> I'm arguing for ages that qualifier before the return type qualify the return type, and the one after the implicit argument. I stand by this.

This and also another reason why storage classes seem to me inferior to type qualifiers in general.

On Mon, Dec 08, 2014 at 02:52:52AM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/8/2014 2:44 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> >On Monday, 8 December 2014 at 10:37:29 UTC, Walter Bright wrote:
> >>Another problem with that is:
> >>
> >>  void func(scope T delegate() dg);
> >
> >Playing the devil's advocate:
> >
> >     void func(scope(T delegate()) dg);
> >     void func(scope(T) delegate() dg);
> 
> Note that:
> 
>     void func(ref T delegate() dg);
> 
> has the same problem. The only way to make dg return a 'ref T' is to use an alias:
> 
>     alias ref T delegate() dg_t;
>     void func(dg_t dg);
> 
> or put 'ref' as a postfix:
> 
>      void func(T delegate() ref dg);
> 
> But if the latter solution is used for 'scope', then it interferes with 'scope this'.

And once we start writing scope(T), we're back to scope being a type
qualifier (aka type constructor) rather than merely a storage class.


T

-- 
What are you when you run out of Monet? Baroque.

On Monday, 8 December 2014 at 09:52:02 UTC, deadalnix wrote:
> I'm arguing for ages that qualifier before the return type qualify the return type, and the one after the implicit argument. I stand by this.

Simple (== easy to remember), and already widely used. I agree.
In addition, for the possibly ambiguous cases with delegates, a compiler warning could be emitted.

On 12/8/2014 8:32 AM, Dicebot wrote:
> This and also another reason why storage classes seem to me inferior to type
> qualifiers in general.

You might change your mind after reading the C++ language spec and noting how ref types are a special rule in everything!

On Monday, 8 December 2014 at 10:37:29 UTC, Walter Bright wrote:
> On 12/8/2014 1:52 AM, deadalnix wrote:
>> On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
>>> I thought I could make this work, but it's a problem. There are two meanings
>>> for scope when attached to a function:
>>>
>>>    T func() scope;   // the 'this' pointer is 'scope'
>>>    scope T func();   // the function returns a 'scope' T
>>>
>>> I have some ideas, but don't particularly like any of them. But I don't want
>>> to bias things, so what ideas do you guys have?
>>
>> I'm arguing for ages that qualifier before the return type qualify the return
>> type, and the one after the implicit argument. I stand by this.
>
> Another problem with that is:
>
>   void func(scope T delegate() dg);

Nop. I actually made a proposal that was more complete and
handled such case.

qualifier on the left qualify the return type. qualifier in
between return type and function/delegate qualify both the symbol
and the context (it implicit parameter) and qualifier on the
right qualify only the context.

On 12/8/2014 11:57 AM, deadalnix wrote:
> On Monday, 8 December 2014 at 10:37:29 UTC, Walter Bright wrote:
>> On 12/8/2014 1:52 AM, deadalnix wrote:
>>> On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:
>>>> I thought I could make this work, but it's a problem. There are two meanings
>>>> for scope when attached to a function:
>>>>
>>>>    T func() scope;   // the 'this' pointer is 'scope'
>>>>    scope T func();   // the function returns a 'scope' T
>>>>
>>>> I have some ideas, but don't particularly like any of them. But I don't want
>>>> to bias things, so what ideas do you guys have?
>>>
>>> I'm arguing for ages that qualifier before the return type qualify the return
>>> type, and the one after the implicit argument. I stand by this.
>>
>> Another problem with that is:
>>
>>   void func(scope T delegate() dg);
>
> Nop. I actually made a proposal that was more complete and
> handled such case.
>
> qualifier on the left qualify the return type. qualifier in
> between return type and function/delegate qualify both the symbol
> and the context (it implicit parameter) and qualifier on the
> right qualify only the context.

This would be inconsistent with the rest of the types, where qualifier on the left affects the symbol.

But I like the idea of:

   T scope delegate() dg;

as meaning the scope affects the return type. Is that what you meant?

On Monday, 8 December 2014 at 20:14:23 UTC, Walter Bright wrote:
> This would be inconsistent with the rest of the types, where qualifier on the left affects the symbol.
>
> But I like the idea of:
>
>    T scope delegate() dg;
>
> as meaning the scope affects the return type. Is that what you meant?

No I mean the reverse. Let's make it with const as it is better
understood by everybody, and at the end we discuss grammar, so it
doesn't matter.

const A delegate() a; // A mutable delegate that return a const(A)
A const delegate() a; // A const delegate with a const context
(context is transitive) and return an A.
A delegate() const a; // A mutable delegate with a const context
that return an A.

You have inherently 3 things to qualify when it come to delegate:
the return type, the context and the delegate itself.

Yes, that create an inconsistency in the grammar. On the other
hand, that allow for much more consistency in other aspect of the
language. If consistency is a measure, the proposal is a winner.

Relevant: http://wiki.dlang.org/DIP30

On Monday, 8 December 2014 at 20:42:49 UTC, deadalnix wrote:
>
> No I mean the reverse. Let's make it with const as it is better
> understood by everybody, and at the end we discuss grammar, so it
> doesn't matter.
>
> const A delegate() a; // A mutable delegate that return a const(A)
> A const delegate() a; // A const delegate with a const context
> (context is transitive) and return an A.
> A delegate() const a; // A mutable delegate with a const context
> that return an A.
>
> You have inherently 3 things to qualify when it come to delegate:
> the return type, the context and the delegate itself.
>
> Yes, that create an inconsistency in the grammar. On the other
> hand, that allow for much more consistency in other aspect of the
> language. If consistency is a measure, the proposal is a winner.
>
> Relevant: http://wiki.dlang.org/DIP30

+1!
---
Paolo