Re: Proposal: __not(keyword)
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
Re: Proposal: __not(keyword)
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.
Re: Proposal: __not(keyword)
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
Re: Proposal: __not(keyword)
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.
Re: Proposal: __not(keyword)
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.
Re: Proposal: __not(keyword)
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.
