On Thursday, 17 July 2025 at 16:28:25 UTC, monkyyy wrote:

If you want a language that rejects pretty much only syntax errors and nothing else, Forth might be what you want, being typeless by default.

However, D isn't and does not try to be that kind of a langauge. It is explicitly the purpose of it's type system to not only add expressive power, but also guard against errors when you want it to. Same with most other languages too, although it varies how low/high they let you to set the guard rails.

It is certainly fun when you can do all sorts of tricks with the language, but sometimes you want to be careful with what you make, or just get fed up with hunting down your own bugs. In those cases, it's nice if your language has mechanisms to prevent errors. D tries to give you the guard rails when you want them, but also to remove them when you don't want them.

In the case of @safe and private, can't you simply not use them when they get in the way? Mark your function @system, and bye bye safety checks. If someone else marks a struct or class field private and you want to use it, .tupleof does the trick. Well, if it is a private function or global variable, then I'm not sure there is a way, but I would rather have D solve it by some module-level equivalent to .tupleof rather than a compiler switch, if it needs solving at all.

As for immutable, there could potentially be a case where you would want to disable the compiler assumption related to it (NOT the type errors from mutating immutables, you can shut those up with a cast). You might have some unrelated problem and wish to work around it by mutating a string in place, for lack of better solutions. Since that is undefined behaviour, a compiler flag to disable read-only memory and const/immutable assumptions would be what you want.

Still, you could say the about any assumptions the compiler is normally allowed to make, such as "ints are not pointers in disguise". Are there often problems that the particular hack of mutating immutable data would resolve?

On Thursday, 17 July 2025 at 18:05:08 UTC, Dukc wrote:

Modifying strings live with range hacks instead of generally handholding it during several layers

Immutablity of strings mainly prevents segfualts of attempting to modify litterals in my code, thats the os being annoying but sometimes it does get a line number that needs a .dup

Im generally using my own data structures, but if phoboes shipped more useful ones(im imagining python-like datastructure aware filters on opIndex being something that could be a use, and would guaranteed embrace these harmful ideas) I imagine there would be more cases of unnecessary immutably

Other people make mistakes, its very sad; I dont actually want to be as independent as adr sitting on my 100000 lines of code after 10 years.

On Thursday, 17 July 2025 at 18:05:08 UTC, Dukc wrote:

Imagine you want to use a library that have this function:

void coolFunction(void function() @nogc nothrow @safe pure callback) @nogc nothrow @safe pure

Now you are forced to satisfy all these attributes, even if you don’t care.

On Friday, 18 July 2025 at 16:43:19 UTC, Ogi wrote:

void coolFunction(void function() @nogc nothrow @safe pure callback) @nogc nothrow @safe pure

Except you can cast function pointers to less-qualified function pointers.
The big issue with doing this, for example with nothrow, is that depending on the platform the code generation will differ in a way that where if your code throws something anyways; it will cause your application to segfault instead as it corrupts the stack.

On Thursday, 17 July 2025 at 20:12:46 UTC, monkyyy wrote:

Depending on where the string comes from this would cause you to write to read-only memory,
causing your application to segfault; sometimes randomly.

If you know the string is in rw memory; just (cast(char[])myString), no?

Enforcing types invariance is a good thing, not harmful given it not only signals the possibility of the data to be read-only; but also the behaviour of the compiler during codegen.

Sometimes things are private for a reason; for example if the implementation details of them would break some sort of state management if used improperly that would segfault your application. As for safe; it exists to prevent code from doing stupid things that should be relegated to low level libraries that have no choice.

It's a good thing it exists as it prevents a large class of error scenarios (and security weaknesses) from sneaking into code that may be hosting your bank details or whatever.

I very much am unsure what you're trying to say there. The D ecosystem needs high quality packages to be written for it for it to be more widely useful. And that entails people sitting down and doing the necessary work of writing D native code that fits within the D paradigm.

On Friday, 18 July 2025 at 16:43:19 UTC, Ogi wrote:

void coolFunction(void function() @nogc nothrow @safe pure callback) @nogc nothrow @safe pure

Yeah, that's annoying, but it depends on the library. Some stuff might benefit from this constraint. And worse case, you just cast and then you are done. Anyway, both private and attributes are useful. To be honest, I only like @safe @trusted @system, but eh. I will be a good person and support pure too.

Back to the original DIP idea. You can just don't use stuff if you don't like em!!

On Saturday, 19 July 2025 at 20:58:39 UTC, Luna wrote:

Its all function coloring and if theres 5 layers of meta programming thats using a string. The same case for, nogc std and safe by default can also be made for "strng=char[]" I either adopt a lib writers opinions, or I rewrite it from scratch.

Other people fundamentally believe more keyword spam is good style. I can name a few places in phoboes where my usecase was blocked by "contact oriented programming" or a random private,that if I had a reason way to go delete it, my usecase would just work

When in wasm, one of phoboes io functions's contract imported something that brought in all of phoboes(and I wasnt at the time implementing a real wasm runtime), the copy and pasted function just worked

Sumtype get!(int) is the exact api I would suggest for extending sumtypes to work with ranges, its private

sort asserts on you using a probabilistic comparison

etc. etc. etc.

Safety is just one of many color of functions, theres plenty of historical president for coloring functions to be more safe like the dip's

On Sunday, 20 July 2025 at 00:39:14 UTC, monkyyy wrote:

This is mostly a library design issue. And to be fair, phoboes has to make everyone happy, so it can't really ignore some things. Standard libraries are kinda like that, especially "battery included" ones.

Btw, you can't avoid function coloring. Even C has it, but it's mostly a runtime problem there instead of a compile time problem.