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.

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.

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.

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.

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

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.

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