On Tuesday, 26 December 2023 at 14:46:45 UTC, Paulo Pinto wrote:

Aside from the massive amounts of money those languages had to start with, the primary use case of Go, Swift, and C# was not working with C, and Rust was explicitly written for someone wanting safe at all costs.

D's primary selling point for many is interoperability with C and otherwise writing unsafe code. Not only would this break almost all of my existing code for no benefit, it would break any package I want to work with that uses unsafe code (anything on code.dlang.org that does anything with a pointer), so then I'm having to maintain my own fork of those packages. All the documentation and tutorials with even one line of unsafe code are suddenly broken.

If D had been safe by default, this would not have been a big issue, even for those of us that don't care about safe by default. But to force this on us entirely because you don't want to add a -safe switch to the compiler is completely unreasonable. (The compiler switch was off the table, but the way you tested out the earlier DIP was by using a compiler switch.)

On Tuesday, 26 December 2023 at 12:00:13 UTC, Sebastiaan Koppe wrote:

I understand, you got a point, it makes the ecosystem better, so i'm probably wrong here

But i personally don't use any of these attribute in my code bases, they are pure annoyances, most of the time

Will it solve problems like these?

https://github.com/dlang/dub/issues/2600

https://forum.dlang.org/thread/mjmufdnrcexliatzgkwh@forum.dlang.org

I'd rather see time spent working on getting features that help people's code compile faster (dub doubled their compile time by starting to use std.sumtype) instead of making more of them no longer compile because they do not comply with dmd @christmas tree decoration edition

Let's put it that way, if most of my code consist of low level bits, why should i mark everything @unsafe? I view unsafe as a feature, not as a bug

I hope it'll be toggleable with a compiler flag

On Tuesday, 26 December 2023 at 14:46:45 UTC, Paulo Pinto wrote:

Microsoft sells tooling and services, they have an army of "evangelists" to corrupt, i mean to lobby companies / governments all around the world, these people are driven by an economical motive to vendor lock you

Same for Apple/Swift, and same for Google/Go

Rust is similar, as it consist of a conglomerate of them all

I don't use D because i want corporate-credibility, i use it because it gets the job done faster than anything else (is it even still the case btw?)

On Tuesday, 26 December 2023 at 07:05:48 UTC, Hors wrote:

The correct way forward on this is to enable inference of @safe for (almost) all functions. No existing projects will break, and if you don't use any unsafe language features (pointer arithmetic, casting), your code will automatically become @safe with no intervention required.

Adam Ruppe has a good writeup of this approach on his blog: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_07_11.html#inferred-attributes

On Tuesday, 26 December 2023 at 15:35:55 UTC, Lance Bachmeier wrote:

Cgo has been part of Go since the early days, Swift has been designed with interoperability with Objective-C (a C superset), and C++ has been supported in .NET since version 1.0 (yet another C superset).

How is that selling point going on since Andrei's book has been published, in terms of D market share versus all newcomers?

On which forum post am I advocating against -safe switch?

On Tuesday, 26 December 2023 at 17:27:46 UTC, ryuukk_ wrote:

Hardly, unfortunately, unless there are libraries available, which is increasingly harder as many aren't updated to keep up with D vlatest.

Which makes this safety discussion a moot point, too late to change it, even with the languages that prove otherwise, those libraries wouldn't be updated to safety by default.

On Tuesday, 26 December 2023 at 13:18:43 UTC, Hors wrote:

An elephant in the room is the -dip1000 switch. Should or shouldn't it be enabled for the new *.safeD files? Here's an interesting old topic, where a beginner tried to explore the safety offered by D language: https://forum.dlang.org/thread/duwrxnkjaafnzpfgnted@forum.dlang.org

On Wednesday, 27 December 2023 at 07:42:31 UTC, Walter Bright wrote:

My understanding is that people are suggesting a new global compiler switch to optionally disable safety (allow @system and @trusted to be called from @safe), which would indeed allow compiling old abandoned libraries and use them from the new code during the transition period.