digitalmars.D - DIP69: problem with scope grammar - need a new keyword
- Walter Bright (6/6) Dec 08 2014 I thought I could make this work, but it's a problem. There are two mean...
- deadalnix (4/10) Dec 08 2014 I'm arguing for ages that qualifier before the return type
- John Colvin (2/15) Dec 08 2014 Agreed.
- Daniel N (2/7) Dec 08 2014 FWIW: I'm in the same camp.
- Walter Bright (3/14) Dec 08 2014 The trouble with that is, for example, __traits(getFuncAttributes, ...) ...
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (3/23) Dec 08 2014 Why would it? A qualifier/stc for the implicit `this` parameter
- Walter Bright (2/21) Dec 08 2014 That's a good point, but it currently returns 'ref' returns as an attrib...
- Walter Bright (3/14) Dec 08 2014 Another problem with that is:
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (4/23) Dec 08 2014 Playing the devil's advocate:
- Walter Bright (10/17) Dec 08 2014 Note that:
- H. S. Teoh via Digitalmars-d (6/33) Dec 08 2014 And once we start writing scope(T), we're back to scope being a type
- deadalnix (7/26) Dec 08 2014 Nop. I actually made a proposal that was more complete and
- Walter Bright (6/30) Dec 08 2014 This would be inconsistent with the rest of the types, where qualifier o...
- deadalnix (15/21) Dec 08 2014 No I mean the reverse. Let's make it with const as it is better
- Paolo Invernizzi (4/22) Dec 08 2014 +1!
- ketmar via Digitalmars-d (3/4) Dec 08 2014 ah, it seems to me that consistency never had high priority.
- Dicebot (3/16) Dec 08 2014 This and also another reason why storage classes seem to me
- Walter Bright (3/5) Dec 08 2014 You might change your mind after reading the C++ language spec and notin...
- Mathias LANG (4/7) Dec 08 2014 Simple (== easy to remember), and already widely used. I agree.
- Rikki Cattermole (5/11) Dec 08 2014 T func() scope(this);
- John Colvin (3/9) Dec 08 2014 You could make the 2nd an error and insist on it being written
- bearophile (15/17) Dec 08 2014 In this thread I have seen lot of discussion about the location
- ketmar via Digitalmars-d (5/23) Dec 08 2014 oh, please, no! what's wrong with double keywords? ah, except that
- Manu via Digitalmars-d (4/10) Dec 09 2014 The solution is obvious; function should return scope(T)
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
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
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:Agreed.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
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:FWIW: I'm in the same camp.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
On 12/8/2014 1:52 AM, deadalnix wrote:On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:The trouble with that is, for example, __traits(getFuncAttributes, ...) which will return "scope" for both cases.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
On Monday, 8 December 2014 at 10:34:42 UTC, Walter Bright wrote:On 12/8/2014 1:52 AM, deadalnix wrote:Why would it? A qualifier/stc for the implicit `this` parameter is not a function attribute.On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:The trouble with that is, for example, __traits(getFuncAttributes, ...) which will return "scope" for both cases.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
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:That's a good point, but it currently returns 'ref' returns as an attribute.On 12/8/2014 1:52 AM, deadalnix wrote:Why would it? A qualifier/stc for the implicit `this` parameter is not a function attribute.On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:The trouble with that is, for example, __traits(getFuncAttributes, ...) which will return "scope" for both cases.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
On 12/8/2014 1:52 AM, deadalnix wrote:On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:Another problem with that is: void func(scope T delegate() dg);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
On Monday, 8 December 2014 at 10:37:29 UTC, Walter Bright wrote:On 12/8/2014 1:52 AM, deadalnix wrote:Playing the devil's advocate: void func(scope(T delegate()) dg); void func(scope(T) delegate() dg);On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:Another problem with that is: void func(scope T delegate() dg);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
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: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'.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
On Mon, Dec 08, 2014 at 02:52:52AM -0800, Walter Bright via Digitalmars-d wrote:On Monday, 8 December 2014 at 10:37:29 UTC, Walter Bright wrote:On 12/8/2014 1:52 AM, deadalnix wrote: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 Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:Another problem with that is: void func(scope T delegate() dg);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 2014On 12/8/2014 11:57 AM, deadalnix wrote:On Monday, 8 December 2014 at 10:37:29 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?On 12/8/2014 1:52 AM, deadalnix wrote: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 Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:Another problem with that is: void func(scope T delegate() dg);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 2014On 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/DIP30Dec 08 2014On 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! --- PaoloDec 08 2014On 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 2014On Monday, 8 December 2014 at 09:52:02 UTC, deadalnix wrote:On Monday, 8 December 2014 at 09:46:03 UTC, Walter Bright wrote:This and also another reason why storage classes seem to me inferior to type qualifiers in general.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 2014On 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 2014On 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 2014On 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 2014On 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 2014Walter 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, bearophileDec 08 2014On Mon, 08 Dec 2014 23:15:25 +0000 bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:Walter Bright: =20oh, 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...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.Dec 08 2014On 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