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----------------------

>  Fortunately, the solution is easy, although tedious: annotate functions that aren't safe with @trusted or @system.

If you could annotate the module with @system to use the old behavior, this will ease the transition period. This is better than simply having a compiler flag that changes behavior, as you can see in the code that is using the old behavior. You can also disable it per module, not either on or off for everything.


    @system module std.stdio; // or similar


C# and Rust both are first class citizens for safety, they don't require hacks like using a lambda to declare a section of code as unsafe as you have to do in D.


@safe void foo() {

    // ...

    () @trusted {
        // ...
    } ();

    // ...
}

Since this DIP is so bare bones anyways, I'd be inclined to include these changes as part of this DIP.

On Thu, Jan 02, 2020 at 05:27:22PM +0000, Arine via Digitalmars-d wrote:
> >  Fortunately, the solution is easy, although tedious: annotate
> >  functions that aren't safe with @trusted or @system.
> 
> If you could annotate the module with @system to use the old behavior, this will ease the transition period. This is better than simply having a compiler flag that changes behavior, as you can see in the code that is using the old behavior. You can also disable it per module, not either on or off for everything.
> 
> 
>     @system module std.stdio; // or similar

You can already do this today:

	module blah;
	@system:
	... // everything here defaults to @system

Of course, today this does nothing because @system is the default, but you can already mark an entire module as @safe the same way, for example.


T

-- 
This is not a sentence.

On Thursday, 2 January 2020 at 16:19:00 UTC, jmh530 wrote:
> On Thursday, 2 January 2020 at 15:25:15 UTC, bachmeier wrote:

> Your @legacy is really no different than putting @trusted: at the top. I agree with others who are concerned about marking all current code as @trusted, rather than @system.

It would be treated that way. In practice, it would mean something very different from @trusted, because all you can infer from the lack of attributes at this point is that there was never a decision made with respect to @safe, @trusted, or @system. If you put @trusted at the top of a file, that should mean you've made the decision to call it @trusted after evaluating and testing the code. Going forward, anything marked @trusted really would be @trusted if we had @legacy.

> To your other point about it being ugly to mark main as @system, I recall Walter considering, at some point, keeping main as @system. Perhaps give main more time before changing the default to @safe?

That would certainly be better. It would still not prevent unnecessarily breaking (many millions of lines of) working code.

On Thursday, 2 January 2020 at 17:06:44 UTC, Guillaume Piolat wrote:
> - I don't think D defaults are wrong, they let you write code that is as-crappy-as-needed and gets better later.
>

Personally, I don't care for memory safety either, I don't write any critical software or anything like that so crashes are not much of a concern for me. But I think there is value in forcing safe defaults. With languages like C# or Rust, which are safe by default and allow unsafe sections, when you encounter a crash, usually all you have to do is just go over the unsafe sections (which should be rare and limited in size) to find the culprit.

I don't believe in "write crappy as needed and get better later" methodology, because that later usually never happens. And if you didn't write the safe code from the start, it's much harder to convert a codebase. Meanwhile, if you're writing it safe from the scratch, it's much easier as long as you follow some rules.

On Thursday, 2 January 2020 at 09:47:48 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
>
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 16, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

Since this breaks virtually all code out there I suggest that safe by default will be a compiler option only. Anyone who wants the functions to be safe by default must specify so in the compiler options or the build system.

Also many people here don't care about this "safe" trend right now. The feature is good but cannot be enforced because of backwards compatibility. Maybe in D3.

On 1/2/2020 1:47 AM, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1028, "Make @safe the Default":
> 
> https://github.com/dlang/DIPs/blob/1b705f8d4faa095d6d9e3a1b81d6cfa6d688554b/DIPs/DIP1028.md

Implementation:

https://github.com/dlang/dmd/pull/10709

On 1/2/2020 6:39 AM, 12345swordy wrote:
> This issue is major blocking point
Issues that don't get put in bugzilla don't get fixed. Please tag all issues about @safe with the `safe` keyword. Here is the current list:

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=229570&query_format=advanced

On 1/2/2020 6:39 AM, 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. 

Issues with @safe that are not about making @safe the default (i.e. not about the DIP) are off-topic. Please start a new thread with them.

On 1/2/2020 3:19 AM, jmh530 wrote:
> I believe this DIP should be not be accepted until 1) it is possible to write a @safe RC type,

Issues that don't get put in bugzilla don't get fixed. Please tag all issues about @safe with the `safe` keyword. Here is the current list:

https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=229570&query_format=advanced

Issues with @safe that are not about making @safe the default (i.e. not about the DIP) are off-topic. Please start a new thread with them.