July 08

On Monday, 8 July 2024 at 14:08:49 UTC, Dom DiSc wrote:

>

On Monday, 8 July 2024 at 13:20:45 UTC, bachmeier wrote:

>

We have very few details on what this will look like for someone that doesn't want it. Not breaking existing code is far from sufficient for those writing unsafe code.

Sorry, but having unsafe code is burden enough.

This is not helpful. If the biggest selling point is working with legacy C code, unsafe code needs to be a core part of the language, and it needs to be as easy as possible. (As in, as easy as it is right now.)

>

I don't see any need to help people continue to write unsafe code.

D will quickly die without unsafe code. I would certainly have no reason to continue using it. Rust has the small market for "safe by default" code. D can not and will not compete with Rust on this - the battle is over and all parties have moved on.

>

If at all, it is enough that it will be still possible to write unsafe code. Its not required to make that easy.

We can already do it. There's no "make that easy" to do.

>

Why can't those people be bothered with giving -unsafe as compile parameter?

Proposed and rejected. Whereas safe by default is already available with a switch.

July 08

On Monday, 8 July 2024 at 14:08:49 UTC, Dom DiSc wrote:

>

IT SHOULD ALWAYS BE MORE COMPLICATED TO SHOOT YOUR FOOT THAN AVOIDING IT

A dull knife is the dangerous one, safety features just get in the way and you'll get people learning actively awful patterns in an attempt to force the tool to work

To say nothing of the lack of understanding of fail safe vs fail dangerous in cs, safetyphilia is is misplaced and delusional in the degree which I will adopt any of it for a single second. I won't.

July 08
On 7/6/24 16:56, aberba wrote:
>  From another angle, would you choose "less freedom but more security" or "more freedom but less security"? You can't have both.

Arguably, security is a form of freedom.
July 08
On Monday, 8 July 2024 at 15:27:49 UTC, Timon Gehr wrote:
> On 7/6/24 16:56, aberba wrote:
>>  From another angle, would you choose "less freedom but more security" or "more freedom but less security"? You can't have both.
>
> Arguably, security is a form of freedom.

Maybe in some political theories, but on a computer? No

Binary and basically perfect data storage changes the fuzziness/analog required for those political theories.

Either the function has a throw in the code path or it doesnt; either a function throws on nan or treats it as a 0; for each type of error its either the compiler stops or it prints a warning people ignore.

When "safety is nessery for freedom" argument is made politically, at least they are referring to say freedom of movement is limited by the chance of muggers or something and theres at least tradeoffs to consider for humans following instructions poorly and large scale physical systems being inherently probabilistic.
July 08
On Monday, 8 July 2024 at 15:27:49 UTC, Timon Gehr wrote:
> On 7/6/24 16:56, aberba wrote:
>>  From another angle, would you choose "less freedom but more security" or "more freedom but less security"? You can't have both.
>
> Arguably, security is a form of freedom.

"You'll own and control nothing, but you'll be happy"
July 09
On 7/8/24 23:56, aberba wrote:
> On Monday, 8 July 2024 at 15:27:49 UTC, Timon Gehr wrote:
>> On 7/6/24 16:56, aberba wrote:
>>>  From another angle, would you choose "less freedom but more security" or "more freedom but less security"? You can't have both.
>>
>> Arguably, security is a form of freedom.
> 
> "You'll own and control nothing, but you'll be happy"

That has nothing to do with what I said.
July 09
On 7/8/24 18:16, monkyyy wrote:
> On Monday, 8 July 2024 at 15:27:49 UTC, Timon Gehr wrote:
>> On 7/6/24 16:56, aberba wrote:
>>>  From another angle, would you choose "less freedom but more security" or "more freedom but less security"? You can't have both.
>>
>> Arguably, security is a form of freedom.
> 
> Maybe in some political theories, but on a computer? No
> ...

The context here is programming a computer. I don't know why you jump to politics. It's also against the forum guidelines.

The simple fact is that if you program in a language without footguns, you are free to not worry about shooting your own foot. (Assuming you like having feet.)
July 08
On 7/6/2024 9:10 PM, Steven Schveighoffer wrote:
> Typing @safe: is also incorrect. You will cause your templates to fail to compile.

??

July 09
On 7/9/24 01:21, Walter Bright wrote:
> On 7/6/2024 9:10 PM, Steven Schveighoffer wrote:
>> Typing @safe: is also incorrect. You will cause your templates to fail to compile.
> 
> ??
> 

Templates are inferred by default:

```d
auto call(alias a)(){ a(); }

@safe void foo(){}
@system void bar(){}

@safe void fun(){ call!fun(); }
@system void gun(){ call!bar(); }
```

If you annotate `call` with `@safe`, some of those calls will no longer work. It removes functionality even though it was already compatible with `@safe` code.

`@safe:` will put `@safe` on all your function templates, which will make them not work in `@system` contexts even if they worked before.

The issue is that it applies the attribute, when what is needed is a way to change the default attribute.
July 09

On Monday, 8 July 2024 at 14:37:52 UTC, bachmeier wrote:

>

Whereas safe by default is already available with a switch.

What is the switch for that?