On 7/22/24 21:06, claptrap wrote:
> 
>> If a mechanic wants to rebuilt an engine, first he has to dismantle a fair chunk of the car, making things worse.
> 
> I think you're making a false equivalence.

I agree. Walter's approach is more like the Volkswagen emission scandal.

On 7/22/2024 11:51 AM, Timon Gehr wrote:
> What is even the point of this exercise?

To provide a migration path for people who want their code to be safe.

Can't stop people from misusing @trusted.

I appreciate your help with this!

On 7/19/2024 12:43 PM, Dennis wrote:
> Take these numbers with a grain of salt: this doesn't analyze the scope and actual impact of those attributes of course. However, it's hard to believe mass-applying `@trusted` on functions is 'the only practical way'.

The hard problems aren't being tackled, like toChars(). One would think it would be a leaf, but it isn't. It can call semantic(), semantic() can call the parser, and round and round it goes.

There's no place to start.

I haven't found a better way. You saw the problems I had with pretregs in the backend. I finally had to bite the bullet and do a very large PR. And that was simple to do, though very tedious. @safe changes need re-engineering, not just query-search-replace.

I've done similar things in the past. What works is doing things incrementally, passing the test suite with each increment. What doesn't work is do it all at once.


> In my experience, the main obstacles of a `@safe` dmd are abundant use of `__gshared` and C-strings. That's why I appreciate your pull requests where you refactor globals into parameters, those improve the `@safe` situation for real. The DIP idea to make printf's interface `@safe` is also a step in the right direction because `error()` calls are everywhere.

That's one reason to switch to parameters, but there's another: make the compiler "stateless" so it can be a library.

> (though with the bootstrap compiler situation, its usefulness looks very far away).

I don't know why the bootstrap compiler needs to be so old? Back in the olden daze of my compiler, the previous release was the bootstrap version!

On 7/14/2024 6:34 AM, Dukc wrote:
> He has complained that lambdas like `(@trusted { list.list_delete(); })()` are a bad practice, since they hide the fact a `@safe` function is actually calling unsafe functions. But isn't this much worse? Not only are `@safe` functions calling unsafe functions, there isn't even a `@trusted` in the function body to warn about the fact!
> 
> I'd have expected Walter to mark the calling functions `@trusted` instead, if he feels the lambda trick is too dangerous.

It wasn't just me. Quite a few people realized that the @trusted lambda approach did not work.

On 7/22/2024 12:00 PM, Timon Gehr wrote:
> Anyway, the point is there should be a way to have the compiler help you do this kind of safety scaffolding without you needing to lie to the compiler.

I understand your design and it has merit.

Issues:

1. the proliferation of these features. Have you seen all the C extensions VC and gcc have? It makes for an excessively large and intimidating language. The larger the specification, the less people will read it.

2. if an existing feature can be pressed into service instead, adding a new feature needs a big advantage

3. one of the earliest goals with D was to make it easier for managers and QA staff to have rules and enforce them. @trusted was always intended to be an easily greppable construct so that the QA reviewer knows where to focus his effort. A manager can lay down a rule "no level1 programmers can check in @trusted" and enforce it mechanically.

4. @trusted makes for a nice and easily grepped TODO list to measure progress on making the code actually safe

5. In a final release, @trusted should be quite rare. But it's up to the team to enforce it.

6. @trusted can absolutely be abused. But you can't hide it!

7. Simple is better.

8. Not needing to learn new things is better.

On 7/25/24 03:49, Walter Bright wrote:
> On 7/22/2024 11:51 AM, Timon Gehr wrote:
>> What is even the point of this exercise?
> 
> To provide a migration path for people who want their code to be safe.
> ...

You mean `@safe`. It will not be safe.

> Can't stop people from misusing @trusted.

In this thread, you have been actively encouraging people to misuse `@trusted`.

On 7/25/24 04:32, Walter Bright wrote:
> On 7/22/2024 12:00 PM, Timon Gehr wrote:
>> Anyway, the point is there should be a way to have the compiler help you do this kind of safety scaffolding without you needing to lie to the compiler.
> 
> I understand your design and it has merit.
> 
> Issues:
> 
> 1. the proliferation of these features. Have you seen all the C extensions VC and gcc have? It makes for an excessively large and intimidating language. The larger the specification, the less people will read it.
> ...

Hardly applies in any relevant fashion to pragmas that enable additional type checking.

> 2. if an existing feature can be pressed into service instead, adding a new feature needs a big advantage
> ...

You are in effect removing an existing feature.

> 3. one of the earliest goals with D was to make it easier for managers and QA staff to have rules and enforce them. @trusted was always intended to be an easily greppable construct so that the QA reviewer knows where to focus his effort. A manager can lay down a rule "no level1 programmers can check in @trusted" and enforce it mechanically.
> ...

Well, your approach is essentially that your higher-level programmers go around slapping `@trusted:` on files. I'll give you that banning "level1 programmers" from checking in any code at all probably does help safety.

> 4. @trusted makes for a nice and easily grepped TODO list to measure progress on making the code actually safe
> ...

No, some uses of `@trusted` are inevitable. `@trusted` means: "this has been audited and the author certifies that the interface is safe".

What you are describing is not `@trusted`, you are describing `@yolo`: "this has not been audited at all but I need it to be `@safe` anyway for marketing purposes".

> 5. In a final release, @trusted should be quite rare. But it's up to the team to enforce it.
> ...

Well, what do you think I am doing here? You are behaving in a way I deem irresponsible by promoting this way of using `@trusted`.

> 6. @trusted can absolutely be abused. But you can't hide it!
> ...

I am putting forward a critique of that abuse, which is indeed plainly visible.

> 7. Simple is better.
> ...

Apparently `@trusted` is already too complex for most people to wrap their heads around it. It's a pity.

> 8. Not needing to learn new things is better.

The way you suggest `@trusted` should be used is a novelty. It's a completely new attribute.

On Thursday, 25 July 2024 at 11:47:21 UTC, Timon Gehr wrote:
> On 7/25/24 04:32, Walter Bright wrote:
>> On 7/22/2024 12:00 PM, Timon Gehr wrote:
>>> Anyway, the point is there should be a way to have the compiler help you do this kind of safety scaffolding without you needing to lie to the compiler.
>> 
>> I understand your design and it has merit.
>> 
>> Issues:
>> 
>> 1. the proliferation of these features. Have you seen all the C extensions VC and gcc have? It makes for an excessively large and intimidating language. The larger the specification, the less people will read it.
>> ...
>
> Hardly applies in any relevant fashion to pragmas that enable additional type checking.
>
>> 2. if an existing feature can be pressed into service instead, adding a new feature needs a big advantage
>> ...
>
> You are in effect removing an existing feature.
>
>> 3. one of the earliest goals with D was to make it easier for managers and QA staff to have rules and enforce them. @trusted was always intended to be an easily greppable construct so that the QA reviewer knows where to focus his effort. A manager can lay down a rule "no level1 programmers can check in @trusted" and enforce it mechanically.
>> ...
>
> Well, your approach is essentially that your higher-level programmers go around slapping `@trusted:` on files. I'll give you that banning "level1 programmers" from checking in any code at all probably does help safety.
>
>> 4. @trusted makes for a nice and easily grepped TODO list to measure progress on making the code actually safe
>> ...
>
> No, some uses of `@trusted` are inevitable. `@trusted` means: "this has been audited and the author certifies that the interface is safe".
>
> What you are describing is not `@trusted`, you are describing `@yolo`: "this has not been audited at all but I need it to be `@safe` anyway for marketing purposes".
>
>> 5. In a final release, @trusted should be quite rare. But it's up to the team to enforce it.
>> ...
>
> Well, what do you think I am doing here? You are behaving in a way I deem irresponsible by promoting this way of using `@trusted`.
>
>> 6. @trusted can absolutely be abused. But you can't hide it!
>> ...
>
> I am putting forward a critique of that abuse, which is indeed plainly visible.
>
>> 7. Simple is better.
>> ...
>
> Apparently `@trusted` is already too complex for most people to wrap their heads around it. It's a pity.
>
>> 8. Not needing to learn new things is better.
>
> The way you suggest `@trusted` should be used is a novelty. It's a completely new attribute.

I totally agree with Timon here.

Lately I was speaking with a friend of mine, now a senior Nvidia manager, curious about what programming language we are using in DeepGlance as I claimed we care for memory safety. Guess what he should think about this thread, after having pointed it to

https://dlang.org/spec/memory-safe-d.html
"@trusted functions __MUST__ have a safe interface"

when he could see the language main author writing: `@trusted void list_delete(list_t list) { free(list); }`, advocating to slap trusted everywhere?

How you can think someone can just expose himself in advising D stating that??

I understand the problem you put on the table, but that MUST be solved with a new greppable attribute or a pragma, abusing @trusted. There's no plan B.

/P

On Thursday, 25 July 2024 at 12:24:27 UTC, Paolo Invernizzi wrote:
> I understand the problem you put on the table, but that MUST be solved with a new greppable attribute or a pragma, abusing @trusted. There's no plan B.

... NOT abusing @truested  ...