www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP69: problem with scope grammar - need a new keyword

reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Dec 08 2014
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Dec 08 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Agreed.
Dec 08 2014
parent "Daniel N" <ufo orbiting.us> writes:
On Monday, 8 December 2014 at 10:19:03 UTC, John Colvin wrote:
 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.
Agreed.
FWIW: I'm in the same camp.
Dec 08 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 08 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Dec 08 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 08 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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);
Dec 08 2014
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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);
Playing the devil's advocate: void func(scope(T delegate()) dg); void func(scope(T) delegate() dg);
Dec 08 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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'.
Dec 08 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Dec 08, 2014 at 02:52:52AM -0800, Walter Bright via Digitalmars-d wrote:
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Dec 08 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Dec 08 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
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
Dec 08 2014
next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
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
Dec 08 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 20:42:48 +0000
deadalnix via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 If consistency is a measure, the proposal is a winner.
ah, it seems to me that consistency never had high priority.
Dec 08 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Dec 08 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
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!
Dec 08 2014
prev sibling parent "Mathias LANG" <geod24 gmail.com> writes:
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.
Dec 08 2014
prev sibling next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 8/12/2014 10:45 p.m., 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'
T func() scope(this); or: T func(scope(this), ARGS); It is theoretically the first argument after all.
      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?
Dec 08 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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)
Dec 08 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 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?
In this thread I have seen lot of discussion about the location of const for struct/class methods, and I agree this is an interesting topic, but one of the most important points of this thread regarding DIP69 scope grammar seems too much ignored, that is the syntax used implementing DIP69 needs to be easy to read, understand, and remember. Overloading keywords meanings rarely helps make code easy to understand. Often if you use a different keyword for a different meaning your language is more easy to understand. Double keywords like "auto ref", "scope ref", "final switch" and more cause some troubles, and I don't like them. I prefer keywords like "auto_ref", "scope_ref", "final_switch", etc. Bye, bearophile
Dec 08 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 08 Dec 2014 23:15:25 +0000
bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Walter Bright:
=20
 I have some ideas, but don't particularly like any of them. But=20
 I don't want to bias things, so what ideas do you guys have?
=20 In this thread I have seen lot of discussion about the location=20 of const for struct/class methods, and I agree this is an=20 interesting topic, but one of the most important points of this=20 thread regarding DIP69 scope grammar seems too much ignored, that=20 is the syntax used implementing DIP69 needs to be easy to read,=20 understand, and remember. Overloading keywords meanings rarely=20 helps make code easy to understand. Often if you use a different=20 keyword for a different meaning your language is more easy to=20 understand. =20 Double keywords like "auto ref", "scope ref", "final switch" and=20 more cause some troubles, and I don't like them. I prefer=20 keywords like "auto_ref", "scope_ref", "final_switch", etc.
oh, please, no! what's wrong with double keywords? ah, except that `shared static this()` is ok and `static shared this()` is not ok, and it has no sane explanation...
Dec 08 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 8 December 2014 at 19:45, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> 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?
The solution is obvious; function should return scope(T) ;)
Dec 09 2014