www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.ideas - Justwerk compiler flag

reply Monkyyy <crazymonkyyy gmail.com> writes:
Disable all anti work keywords on a fundamental level. 
`immutable` ` safe` `private` when passed a flag.
Jul 12
next sibling parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Sunday, 13 July 2025 at 00:12:16 UTC, Monkyyy wrote:

 Disable all anti work keywords on a fundamental level. 
 `immutable` ` safe` `private` when passed a flag.


Hey! Private is useful :(
Jul 12
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 13 July 2025 at 00:52:56 UTC, Kapendev wrote:

 On Sunday, 13 July 2025 at 00:12:16 UTC, Monkyyy wrote:

 Disable all anti work keywords on a fundamental level. 
 `immutable` ` safe` `private` when passed a flag.


 Hey! Private is useful :(


False; it can only make less code work. I understand that some 
have a religious belief that some working code is unholy. However 
I would prefer my computer does what I tell it to do when I tell 
it to do it and not do major reworks if I happen to use code with 
such unnecessary wounds.
Jul 12
next sibling parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Sunday, 13 July 2025 at 01:07:28 UTC, monkyyy wrote:

 On Sunday, 13 July 2025 at 00:52:56 UTC, Kapendev wrote:

 On Sunday, 13 July 2025 at 00:12:16 UTC, Monkyyy wrote:

 Disable all anti work keywords on a fundamental level. 
 `immutable` ` safe` `private` when passed a flag.


 Hey! Private is useful :(


 False; it can only make less code work. I understand that some 
 have a religious belief that some working code is unholy. 
 However I would prefer my computer does what I tell it to do 
 when I tell it to do it and not do major reworks if I happen to 
 use code with such unnecessary wounds.


I do think that having private struct/class fields is sometimes 
annoying, but nothing wrong with private functions.
Jul 13
next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 13 July 2025 at 08:47:30 UTC, Kapendev wrote:

 nothing wrong with private functions.


https://forum.dlang.org/thread/xpmcikgbxhwnraglzbsf forum.dlang.org?page=1

I one symbol typo can cause many problems
Jul 13
prev sibling parent xoxo <xororwr gmail.com> writes:
On Sunday, 13 July 2025 at 08:47:30 UTC, Kapendev wrote:

 On Sunday, 13 July 2025 at 01:07:28 UTC, monkyyy wrote:

 On Sunday, 13 July 2025 at 00:52:56 UTC, Kapendev wrote:

 On Sunday, 13 July 2025 at 00:12:16 UTC, Monkyyy wrote:

 Disable all anti work keywords on a fundamental level. 
 `immutable` ` safe` `private` when passed a flag.


 Hey! Private is useful :(


 False; it can only make less code work. I understand that some 
 have a religious belief that some working code is unholy. 
 However I would prefer my computer does what I tell it to do 
 when I tell it to do it and not do major reworks if I happen 
 to use code with such unnecessary wounds.


 I do think that having private struct/class fields is sometimes 
 annoying, but nothing wrong with private functions.


`private` is bad, grouping `private:` is even worse, it makes 
people write bad software, you should focus on optimizing your 
memory layouts, field order is important
Jul 17
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 13 July 2025 at 01:07:28 UTC, monkyyy wrote:

 False; it can only make less code work. I understand that some 
 have a religious belief that some working code is unholy.


Then again, probably you agree there is *some* code you wouldn't 
want to compile. If I write

```D
SpamSpamSpam$% }}}123€([//
øÅ   rgmh**^||
```

do you think that should compile to something? If not, there you 
have it - there is code that shouldn't work.

The question is, where are you drawing the line - when do 
compiler checks go too far?
Jul 17
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 17 July 2025 at 13:53:24 UTC, Dukc wrote:

 On Sunday, 13 July 2025 at 01:07:28 UTC, monkyyy wrote:

 False; it can only make less code work. I understand that some 
 have a religious belief that some working code is unholy.


 Then again, probably you agree there is *some* code you 
 wouldn't want to compile. If I write

 ```D
 SpamSpamSpam$% }}}123€([//
 øÅ   rgmh**^||
 ```

 do you think that should compile to something? If not, there 
 you have it - there is code that shouldn't work.

 The question is, where are you drawing the line - when do 
 compiler checks go too far?


Failing to parse is different from not working because extra code 
decides its a bad idea; my line would be mostly ()'s matching and 
semicolons for *compiled* *c-like* languages; in a calculator 
every string should return a result.
Jul 17
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 17 July 2025 at 16:28:25 UTC, monkyyy wrote:

 Failing to parse is different from not working because extra 
 code decides its a bad idea; my line would be mostly ()'s 
 matching and semicolons for *compiled* *c-like* languages;


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?
Jul 17
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 17 July 2025 at 18:05:08 UTC, Dukc wrote:

 Are there often problems that the particular hack of mutating 
 immutable data would resolve?


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


 In the case of  safe and private, can't you simply not use them 
 when they get in the way


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.
Jul 17
parent reply Luna <luna foxgirls.gay> writes:
On Thursday, 17 July 2025 at 20:12:46 UTC, monkyyy wrote:

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

 Are there often problems that the particular hack of mutating 
 immutable data would resolve?


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


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


 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


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


 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


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.


 In the case of  safe and private, can't you simply not use 
 them when they get in the way




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.


 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.


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.
Jul 19
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Saturday, 19 July 2025 at 20:58:39 UTC, Luna wrote:

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

 Enforcing types invariance is a good thing,

 Sometimes things are private for a reason; ...
 As for safe; it exists to prevent code from doing stupid things 
 that should be relegated to low level libraries that have no 
 choice.

 your bank details or whatever.


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
Jul 19
parent Kapendev <alexandroskapretsos gmail.com> writes:
On Sunday, 20 July 2025 at 00:39:14 UTC, monkyyy wrote:

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

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

 Enforcing types invariance is a good thing,

 Sometimes things are private for a reason; ...
 As for safe; it exists to prevent code from doing stupid 
 things that should be relegated to low level libraries that 
 have no choice.

 your bank details or whatever.


 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


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.
Jul 20
prev sibling parent reply Ogi <ogion.art gmail.com> writes:
On Thursday, 17 July 2025 at 18:05:08 UTC, Dukc wrote:

 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.


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

```D
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.
Jul 18
next sibling parent Luna <luna foxgirls.gay> writes:
On Friday, 18 July 2025 at 16:43:19 UTC, Ogi wrote:

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

 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.


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

 ```D
 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.


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.
Jul 19
prev sibling parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Friday, 18 July 2025 at 16:43:19 UTC, Ogi wrote:

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

 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.


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

 ```D
 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.


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!!
Jul 19
parent Ogion <ogion.art gmail.com> writes:
On Saturday, 19 July 2025 at 23:48:22 UTC, Kapendev wrote:

 Yeah, that's annoying, but it depends on the library. Some 
 stuff might benefit from this constraint.


Sure, but it would be nice if the library user could opt-out of 
these constraints.


 And worse case, you just cast and then you are done.


No, you really can’t. The second you forcefully pass, say, unsafe 
function to a library, the *whole library* becomes potentially 
unsafe, not just the function that receives callback.

```D
module library;

void function()  safe callback;

void addCallback(void function()  safe cb)  safe {
     callback = cb;
}

void callCallback()  safe => callback();
```

So you it’s not correct to opt-out of constrains at function 
level. It should be done globally.
Jul 27
prev sibling parent reply matheus <matheus gmail.com> writes:
On Sunday, 13 July 2025 at 00:12:16 UTC, Monkyyy wrote:

 Disable all anti work keywords on a fundamental level. 
 `immutable` ` safe` `private` when passed a flag.


I think if you didn't already this will be easier to do with 
openD and should br used as termometer for main branch.

Matheus.
Jul 14
parent Monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 14 July 2025 at 15:09:29 UTC, matheus wrote:

 On Sunday, 13 July 2025 at 00:12:16 UTC, Monkyyy wrote:

 Disable all anti work keywords on a fundamental level. 
 `immutable` ` safe` `private` when passed a flag.


 I think if you didn't already this will be easier to do with 
 openD and should br used as termometer for main branch.

 Matheus.


I am not a compiler dev and adr would likely tell me to fork 
phoboes

I'm only bothering at all with this because there were 3 entire 
reasonable opinions in the help thread
Jul 14