DIP 1028---Make @safe the Default---Community Review Round 1

[Guillaume Piolat]

On Thursday, 2 January 2020 at 14:39:56 UTC, 12345swordy wrote:
> This dip, doesn't describe how to make the destroy function for 
> classes safe, as the class deconstructors don't inherent the 
> attributes from the parent class. This issue is major blocking 
> point on why I don't use D for serious software development for 
> gaming development.(It also the reason why you can't call the 
> destroy function for classes in nogc and nothrow context either)
>

This is a serious concern (destruction and attributes), for 
example if you have the runtime disabled (say you make @nogc 
shared libraries :) ) you NEED to do this in order to have class 
objects: 
https://github.com/AuburnSounds/Dplug/blob/master/core/dplug/core/nogc.d#L85

And then live in your own little D-- universe.

Some hope that ProtoObject would solve this...


--------- About that DIP -------------


- Never needed memory-safety, don't see the point, customers are 
not crying. Will not need it in the future.

- I'll just slap @trusted everywhere and call is a day

- this will break every one of the 100kloc I maintain for no 
benefit to me, so well I sure hope the future memory-safe future 
does materialize... I doubt it, in this one real world view, lots 
of customer care about specific bugs not whole classes of bugs. 
In this regards I think type system "fanciness" is a form of 
early optimization (there, I said it).

- I don't think D defaults are wrong, they let you write code 
that is as-crappy-as-needed and gets better later.

- on intel-intrinsics I've already broken @trusted by slapping it 
(had no choice in most cases), as under @safe you can't do things 
like being passed a pointer and access the 3rd element. This more 
or less guarantees no @safe-based optimization? Type-system with 
@trusted gives really no guarantee at scale.
Replace with slices everywhere? Well we like to pass pointers 
around for audio buffers, not multiple time the same length.

Example:
     void processStuff(const(float)* input, float* output, int n)
   vs
     void processStuff(const(float)[] input, float[] output)

   There is a performance difference.

Also there is a reason you've said "no" to pure and @nogc as type 
constructor and they stayed function attributes.

Again, like shared and pure, like TLS-by-default, this is one 
feature with very little Return on Investment (RoI) but with 
considerable hype on internet forums.


---------------->3----------------------