www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal: __not(keyword)

reply Adam D. Ruppe <destructionator gmail.com> writes:
Here's the simple idea: __not(anything) just turns off whatever 
`anything` does in the compiler.

__not(final) void foo() {} // turns off the final flag (if it is 
set)
__not( nogc) void foo() {} // turns off the  nogc flag (if it is 
set)

__not(const)(int) a; // not const

All it does is invert the flags; the implementation would be like 
`flags &= ~WHATEVER;` so unless it was already set, it does 
nothing and does not check for contradictions.


const:
    int b; // const
   __not(const)(int) a; // not const
immutable:
    int c; // immutable int
    __not(const)(int) a; // still immutable int; there was no 
const set to turn off.


It also affects attrs brought through definitions though:

shared class foo {
    int a; // automatically shared cuz of the above line of code
    __not(shared) int b; // no longer shared
}



This is just a generic way to get the flipped attributes WHICH WE 
DESPERATELY NEED IN ALL SITUATIONS and I don't want to argue over 
keywords line impure and whatever __not(shared) would be called 
etc.
Sep 14 2018
next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Friday, 14 September 2018 at 18:06:55 UTC, Adam D. Ruppe wrote:

 Here's the simple idea: __not(anything) just turns off whatever 
 `anything` does in the compiler.


 From your lips to G*d's ears.
Sep 14 2018
prev sibling next sibling parent reply Eugene Wissner <belka caraus.de> writes:
On Friday, 14 September 2018 at 18:06:55 UTC, Adam D. Ruppe wrote:

 Here's the simple idea: __not(anything) just turns off whatever 
 `anything` does in the compiler.

 __not(final) void foo() {} // turns off the final flag (if it 
 is set)
 __not( nogc) void foo() {} // turns off the  nogc flag (if it 
 is set)

 __not(const)(int) a; // not const

 All it does is invert the flags; the implementation would be 
 like `flags &= ~WHATEVER;` so unless it was already set, it 
 does nothing and does not check for contradictions.


 const:
    int b; // const
   __not(const)(int) a; // not const
 immutable:
    int c; // immutable int
    __not(const)(int) a; // still immutable int; there was no 
 const set to turn off.


 It also affects attrs brought through definitions though:

 shared class foo {
    int a; // automatically shared cuz of the above line of code
    __not(shared) int b; // no longer shared
 }



 This is just a generic way to get the flipped attributes WHICH 
 WE DESPERATELY NEED IN ALL SITUATIONS and I don't want to argue 
 over keywords line impure and whatever __not(shared) would be 
 called etc.


const:
    int b; // const
   __not(const)(int) a; // not const
immutable:
    int c; // immutable int
    __not(const)(int) a; // still immutable int; there was no
const set to turn off.

Makes the code unreadable. You have to count all attributes in 
the file, then negate them. Nobody should write like this and 
therefore it is good, that there isn't something like __not.

For  nogc, pure and so forth there were imho a better proposal 
with a boolean value:
 gc(true),  gc(false), pure(true), pure(false) etc. It is also 
consistent with the existing UDA syntax.
Sep 14 2018
next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Friday, 14 September 2018 at 18:13:49 UTC, Eugene Wissner 
wrote:

 Makes the code unreadable. You have to count all attributes in 
 the file, then negate them. Nobody should write like this and 
 therefore it is good, that there isn't something like __not.

 For  nogc, pure and so forth there were imho a better proposal 
 with a boolean value:
  gc(true),  gc(false), pure(true), pure(false) etc. It is also 
 consistent with the existing UDA syntax.


The two proposals are extremely similar in effect. Under Adam D 
Ruppe's proposal, I could write:

__not( nogc) void foo() {}

Here,  nogc wasn't set, so I didn't need to specify any 
attributes. If  nogc: had been specified a thousand times just 
above this function, __not( nogc) would still make `foo` be 
not- nogc.

Identically, under your proposal, I could write:

 gc(true) void foo() {}

If this is the entire file, the annotation has no effect. If 
 gc(false) had been specified a thousand times just above this 
function, the annotation would still make `foo` be not- nogc.

There's no counting of attributes to negate. You just negate 
everything that doesn't apply to this function.
Sep 14 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, September 14, 2018 12:44:11 PM MDT Neia Neutuladh via 
Digitalmars-d wrote:

 On Friday, 14 September 2018 at 18:13:49 UTC, Eugene Wissner

 wrote:

 Makes the code unreadable. You have to count all attributes in
 the file, then negate them. Nobody should write like this and
 therefore it is good, that there isn't something like __not.

 For  nogc, pure and so forth there were imho a better proposal
 with a boolean value:
  gc(true),  gc(false), pure(true), pure(false) etc. It is also
 consistent with the existing UDA syntax.


 The two proposals are extremely similar in effect. Under Adam D
 Ruppe's proposal, I could write:

 __not( nogc) void foo() {}

 Here,  nogc wasn't set, so I didn't need to specify any
 attributes. If  nogc: had been specified a thousand times just
 above this function, __not( nogc) would still make `foo` be
 not- nogc.

 Identically, under your proposal, I could write:

  gc(true) void foo() {}

 If this is the entire file, the annotation has no effect. If
  gc(false) had been specified a thousand times just above this
 function, the annotation would still make `foo` be not- nogc.

 There's no counting of attributes to negate. You just negate
 everything that doesn't apply to this function.


The main reason that attr(bool) is better is that it would allow you to do
stuff like use an enum for the bool, so its value could then depend on other
code, meaning that it would work better with metaprogramming. IIRC, at one
point, Andrei actually proposed that we add attr(bool), but it never
actually went anywhere. I expect that it would stand a good chance of being
accepted if proposed via DIP (especially if a dmd PR were provided at the
same time).

- Jonathan M Davis
Sep 14 2018
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 14 September 2018 at 18:13:49 UTC, Eugene Wissner 
wrote:

 Makes the code unreadable.


It is the foo: that causes this, not the __not...


 For  nogc, pure and so forth there were imho a better proposal 
 with a boolean value:
  gc(true),  gc(false), pure(true), pure(false) etc. It is also 
 consistent with the existing UDA syntax.


Yes, I still actually prefer that proposal, but it has been 
around for a long time and still isn't here.

I want something, ANYTHING to unset these things. I don't care 
which proposal or which syntax, I just want it to be possible.
Sep 15 2018
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/14/18 11:06 AM, Adam D. Ruppe wrote:


 It also affects attrs brought through definitions though:
 
 shared class foo {
     int a; // automatically shared cuz of the above line of code
     __not(shared) int b; // no longer shared
 }


Aside from Jonathan's point, which I agree with, that the cost(bool) 
mechanism would be preferable in generic code (think not just negating 
existing attributes, but determining how to forward them), the above is 
different then just negation.

Making something unshared *inside* something that is shared breaks 
transitivity, and IMO the above simply would be the same as not having 
any attribute there.

In other words, I would expect:

shared foo f;

static assert(is(typeof(f.b)) == shared(int));

I'm not sure how the current behavior works, but definitely wanted to 
clarify that we can't change something like that without a major 
language upheaval.

-Steve
Sep 15 2018