https://issues.dlang.org/show_bug.cgi?id=14389

Adam D. Ruppe <destructionator@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |destructionator@gmail.com

--- Comment #1 from Adam D. Ruppe <destructionator@gmail.com> ---
class C {
   private:
   @safe:
     void foo() {}
}

Should foo still be private? I think a lot of people use this pattern today and expect foo to be private and @safe. Your change would make the @safe turn private off.

You expanded on chat to say it should be written

private @safe:
  void foo() {}

if you want both, put them both behind the colon. That's not a bad idea, I'll admit.

--

https://issues.dlang.org/show_bug.cgi?id=14389

--- Comment #2 from Daniel Čejchan <czdanol@gmail.com> ---
@Adam D. Ruppe:(In reply to Adam D. Ruppe from comment #1)
> class C {
>    private:
>    @safe:
>      void foo() {}
> }
> 
> Should foo still be private? I think a lot of people use this pattern today and expect foo to be private and @safe. Your change would make the @safe turn private off.
> 
> You expanded on chat to say it should be written
> 
> private @safe:
>   void foo() {}
> 
> if you want both, put them both behind the colon. That's not a bad idea, I'll admit.

The problem is:

class C {
   private:
   @safe:
     void foo() {}

   public:
     void asd() {} // I don't want this stuff to be @safe!
}

And, if by any chance, you'd want to ALL the stuff be safe, you'd use my other suggestion:

class C {
   @safe::

   private:
     void foo() {}

   public:
     void asd() {} // Aalso safe
}

--

https://issues.dlang.org/show_bug.cgi?id=14389

--- Comment #3 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
or simply introduce syntax to "unattribute" something. this is much more useful, imo, and not breaking any existing code.

by the way:

class C {
private:
@safe:
  void foo() {}

public:
  void asd() @system {} // I don't want this stuff to be @safe!
  // wow, `@system` overrides `@safe` here!
}

this is very sad situation, as we can override `@safe`/`@trusted`/`@system`, but has no way to override `static`, or `final`, or `pure`, or `nothrow`, or...

but:
class C {
final:
  void foo() {}

static:
  void bad() {}

!final:
!static:
  void asd() {} // virtual method, wow!
}

the open question is what `!public` means, for example. i guess it's `private`.

--

https://issues.dlang.org/show_bug.cgi?id=14389

--- Comment #4 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
p.s. the funny technical note: compiler has no mention of "throw" or "impure" functions (i.e. you can't set that flags by simply changing the parser). what compiler has is three states (for `pure`, for example): "not set", "inferring", "set". what is wrong with "not set" is that this means "always infer this" for templates.

--

https://issues.dlang.org/show_bug.cgi?id=14389

--- Comment #5 from Daniel Čejchan <czdanol@gmail.com> ---
n reply to Ketmar Dark from comment #3)
> or simply introduce syntax to "unattribute" something. this is much more useful, imo, and not breaking any existing code.
> 
> this is very sad situation, as we can override `@safe`/`@trusted`/`@system`, but has no way to override `static`, or `final`, or `pure`, or `nothrow`, or...

Unattribute notation would make the code even more messy imo. One would have to remember not only all the attributes he defined before, but also which ones he removed and which he hasn't. That method would also practically double the need of text writing for all attributes except for the cases where you want the attribute to apply till the end. In overwhelming majority of cases in my programming experience, I don't want it. I want just a portion of code to have the same attribute and I want to avoid using {} notation because it makes the code ugly. Not to mention you could forget unattributing some attributes, which could make a mess in the code and there would be nomway how to chceck it, because not removing it would be legitime intent.

--

https://issues.dlang.org/show_bug.cgi?id=14389

--- Comment #6 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
simply resetting 'em all is messy too: then i have to repeat all that `@safe nothrow @nogc` yet again when i changed visibility from `private` to `public`, for example.

and making visibility resets only visibility is even worse, 'cause now i have to remember what resets what.

on the other side, "unattributing" is really necessary, as there is no way to "undo" some attributes at all.

sure, this is a matter of taste. i agree that `attr { ... }` is making code ugly, and i try to avoid writing that when it is possible. but double colons are very easy to miss (and mistype).

yet i see another possibility! ;-)

class A {
@safe: // this will last forever
(nothrow): // and this will be reset on next `id:` or `(id):`
}

this way it's easy to notice what is what, and using `()` suggests at least something. for me it tells "hey, i'm not permanent, hence the brackets here!"

--

https://issues.dlang.org/show_bug.cgi?id=14389

--- Comment #7 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
quickfix:

class A {
@safe: // this will last forever
(nothrow): // and this will be reset on next `id:`
}

--

https://issues.dlang.org/show_bug.cgi?id=14389

--- Comment #8 from Daniel Čejchan <czdanol@gmail.com> ---
I would agree on that, that :: was just a first thing that came to my mind, but I have a feeling that the standard syntax should be used for temporary attribtes instead. I am aware that it would break some code. Though I believe that proper compiler warnings (such as temporar attribute list that affects no members) would catch most of the cases.

--

https://issues.dlang.org/show_bug.cgi?id=14389

--- Comment #9 from Ketmar Dark <ketmar@ketmar.no-ip.org> ---
actually, "standard" is what developers decided to be standard. so if they will bless any variant, it will become standard syntax. ;-)

the thing is that is is very-very hard (almost impossible) to convince developers to introduce breaking change to syntax. but it is possible to convince them to add something that will not break the existing code and will provide good benefits.

--

https://issues.dlang.org/show_bug.cgi?id=14389

Bolpat <qs.il.paperinik@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |qs.il.paperinik@gmail.com
         Resolution|---                         |WONTFIX

--- Comment #10 from Bolpat <qs.il.paperinik@gmail.com> ---
In my opinion, the `attribute:` syntax is only useful in small-ish aggregates that can be overlooked with not much effort. If your scope is larger, large enough that you ask for !pure or the like, don't use blocks.

@Ketmar Dark, !public would just mean: use the default visibility when nothing else is specified. So, !public is public for everything except imports; in that function, it would be really hilarious.

The only `attribute:` I'd consider useful at all is `@safe:` because usually, one is going to write @safe code anyway if you think about including it on top of your module. If some @system function is among others, it can be annotated, as the @trusted wrapper to make it usable.

This whole thing was discussed at lengths in the past years and went nowhere.

--