DIP1028 - Rationale for accepting as is

[Petar]

On Monday, 25 May 2020 at 13:43:07 UTC, Paul Backus wrote:
> On Monday, 25 May 2020 at 13:22:36 UTC, Petar Kirov 
> [ZombineDev] wrote:
>> On Monday, 25 May 2020 at 13:14:51 UTC, Petar Kirov 
>> [ZombineDev] wrote:
>>>
>>> It may be true (of course modulo meta-programming) that it 
>>> doesn't make a difference for the calling code, but I 
>>> personally want have the guarantees that a function that I'm
>>
>> doesn't make a difference for the calling code, but personally
>> I want [to] have the guarantees that a function that I'm
>>
>>> calling is truly @safe (it doesn't contain or call any 
>>> @trusted code, transitively, nor it calls any @safe code, 
>>> which access global variables initialized by @system 
>>> static/module constructors).
>>
>> This is very far from a rigorous definition of "strong 
>> @safe-ty" - but I hope it's just enough for the casual reader 
>> to understand my intention.
>
> I'm sure this is reasonable for your use-case, but I hope you 
> can recognize that this definition of safety is far too narrow 
> to be suitable for a general-purpose programming language 
> (which D purports to be). Most people would like their @safe 
> code to be able to do I/O, for example, despite the fact that 
> it necessarily involves calling @system code under the hood.

I don't want to change the definition of @safe in D, but would 
rather like if D supported @strongSafe, that interested people 
like me could opt into.
I know that worded like this it may sound like too narrow feature 
to add to the language (or at least not having favorable 
complexity/use cases ratio).
So instead, I'd like to have transitive UDAs [1], a feature that 
has been requested by many, for various use cases ;)

[1]: Basically I want to be able to implement function attributes 
like @nogc or nothrow in user-space, but that's a long way from 
now, as first, we need to be able to introspect function bodies.