@safe(bool)

[Nicholas Wilson via Digitalmars-d]

On Friday, 18 August 2017 at 23:11:34 UTC, Jonathan M Davis wrote:
> On Friday, August 18, 2017 03:08:07 Nicholas Wilson via 
> Digitalmars-d wrote:
>> On Friday, 18 August 2017 at 01:43:42 UTC, Jonathan M Davis 
>> wrote:
>> If you think that then I have clearly failed to express the DIP
>> at all.
>> It solves exactly that. I completely fail to see how it is a
>> detriment to anything.
>> The 'whole pile of other stuff' is reduced in further revisions
>> to the DIP.
>
> IMHO, the problem that needs solving is that you can't negate 
> attributes, making stuff like
>
> final:
>
> problematic. DIP 1012 goes way beyond that, and I don't think 
> that that extra stuff is at all worth having, and I do think 
> that it's detrimental. For instance, as it stands, it's 
> relatively easy to figure out whether @safe has been explicitly 
> applied. You can look on the function and look for @safe: or 
> @safe {} which affects it. The same goes for other attributes. 
> But as soon as you can do stuff like create new attributes that 
> combine attributes, you lose that completely. Suddenly. you 
> have to worry about whatever attributes someone came up on 
> their own for their project which apply @safe or final or @nogc 
> or whatever. You can no longer search or grep for an attribute 
> like @safe to see whether it applies.

As I have said before that is a deliberate feature of the DIP and 
not an incidental side product. Many people have requested such a 
feature. It also allows the DIP to solve the export problem:

```d
  version(MyLib_Build)
      enum MyLibExport = dynamicExport;
  else
      enum MyLibExport = dynamicImport;

  // Exported when building the shared object,
  // imported when linking against the shared object.
  @MyLibExport void foo(int x) { ... }
   ```
I get that you dislike that feature: yes you lose the ability to 
see it directly. grep still works (it might take more searches) 
and so does the documentation.

> Similarly, having it be possible to alter the default 
> attributes globally is incredibly bad IMHO. Suddenly, whether 
> your module compiles or not could depend on what settings 
> someone used for the default attributes. That should not be 
> controlled externally. It should be part of the module just 
> like whether a function or variable is const or not is part of 
> the module and not defined externally. IMHO, it makes no sense 
> whatsoever to have something external control attributes any 
> more than it makes sense to control the return types or 
> constness of symbols externally. That should be part of the 
> declarations/definitions of the symbols in question.

That is a separable feature of the DIP, i.e. the DIP still 
functions without it, and if it truly so incredibly bad more 
people will say so.

But, say you are developing for an embedded platform: you have no 
room for libunwind or exception table and can't use the gc. You 
see some library, libFoo, and you think "Aha! that does exactly 
what I need", then you think can I use it? is this library 
@nothrow @nogc?
You could consult the documentation, but that doesn't tell you 
because there are a bunch of templates that dont have explicit 
attributes. You could try altering the examples to be @nothrow 
@nogc, or you could try to build the whole library as @nothrow 
@nogc and get error messages closer to the site of use.
Yes it is niché, but it has its uses.

>[...] , but I don't at all agree that the rest of
> what DIP 1012 is trying to do is beneficial.

It fixes export, allows grouping and manipulation of lists of 
attributes

> I honestly think that what DIP 1012 is trying to do beyond 
> making it possible to negate attributes

Yes,

>is going to make the language worse and code harder to maintain.

No.

> Yes, it will enable some things that you can't do now, but for 
> the most part, I don't think that those things should be 
> enabled. I don't want to have to deal with folks complaining 
> that my library doesn't work right, because they tried a 
> different default for the attributes with it.

Then that library is not for them.

> I don't want to have to worry about trying to get someone 
> else's code to work because they assumed something about the 
> default attributes that does not hold in my case.

Then the library is not for you.

Having to change the default attributes will be a rare occurrence 
(embedded (nothrow, nogc final) security critical (safe).

> I don't want to have to track down every custom attribute that 
> someone came up with just to see whether they actually apply 
> attributes like @safe or nothrow, just so that I can see 
> whether those attributes apply.

-vcg-ast, documentation. But really, how others do you go: I 
really need to know if that some function has a particular 
combination of attributes (serious)?

>I should be able to look at a
> module and see which attributes have been applied to the 
> functions in that module without having to go searching 
> elsewhere.
>
> IMHO, what needs to be solved with the built-in attributes, is 
> the ability to negate the ones that don't have multiple states. 
> With that, what we have now will work just fine. The rest is 
> completely undesirable.

Again I reject that notion.