On Thursday, 17 June 2021 at 17:14:12 UTC, Paul Backus wrote:
> On Thursday, 17 June 2021 at 16:50:28 UTC, Paolo Invernizzi wrote:
>> On Thursday, 17 June 2021 at 16:21:53 UTC, Paul Backus wrote:
...
>
> Yes, that's exactly my point. This can't be solved by changing the language, but it *can* be solved by a good code review process. So we should avoid wasting our time on language-based solutions (like Steven's proposal for `@system` blocks in `@trusted` functions), and instead focus on how to improve our code review process so that this kind of brittle `@trusted` code doesn't slip through.

I don't consider it a waste of time to search for language upgrades that would reduce the need for expert code review.  I trust experts significantly less than I trust automated checking (in this context I am one of those less trusted "expert"s).

I like where Steven's proposal was headed, if I understood it correctly, and have a variant to put forward that should be opt-in, with an uncluttered syntax and clear semantics for the long term, or so I believe.

I suggest that we discuss the topic at beerconf where, with any luck, we can converge quickly on understanding.

> ...

You're right that the way to unittest file I/O is to use mock files.

On 6/17/2021 12:15 PM, Sönke Ludwig wrote:
> Am 16.06.2021 um 23:22 schrieb Walter Bright:
>> On 6/16/2021 6:09 AM, Sönke Ludwig wrote:
>>> There are 800 of these in vibe.d alone.
>>
>> That is concerning. But it isn't necessarily cause for redesigning @trusted. For example, I removed (in aggregate) a great deal of unsafe allocation code from the backend simply by moving all that code into one resizable array abstraction.
>>
>> Piece by piece, I've been removing the unsafe code from the backend. There really should be very, very little of it.
> 
> Many of them are external functions that are `@system` when they shouldn't have to be:
>                                        - `() @trusted { return typeid(string).getHash(&ln); }()));`
> - `() @trusted { return allocatorObject(GCAllocator.instance); } ();`
> - `() @trusted { GC.addRange(mem.ptr, ElemSlotSize); } ()`
> - `() @trusted { return sanitize(ustr); } ()`
> - `() @trusted { return logicalProcessorCount(); } ()`
> - ...
> 
> It could be that nowadays a number of those has been made `@safe` already, I'd have to check one-by-one.
> 
> Then there are OS/runtime functions that are not `@safe`, but need to be called from a `@safe` context:
> 
> - `() @trusted { return mkstemps(templ.ptr, cast(int)suffix.length); } ();`
> - ```
>      @trusted {
>          scope (failure) assert(false);
>          return CreateFileW(...);
>      } ();
>      ```
> - ...
> 
> There is also quite some manual memory management that requires `@trusted`. Once we are there with ownership (and ten compiler versions ahead) those can be replaced by some kind custom reference type.
> 
> Then there are some shortcut references as pointers that are necessary because `ref` can't be used for local symbols (lifetime analysis could solve this, too):
> 
> - `auto slot = () @trusted { return &m_core.m_handles[h]; } ();`
> 
> There are surely some places that can be refactored to push `@trusted` further down, but right now most of them can't in a meaningful way.

Things like logicalProcessorCount() surely can be @safe.

m_core.m_handles[h] looks like it needs encapsulation in a proper function that takes m_core and h as arguments.

I got rid of a *lot* of memory management code in the back end by creating a container type to do it and prevent a safe interface.

Unsafe system calls like CreateFileW() can be encapsulated with a wrapper that presents a safe interface.

Yes, this is extra work. But it's good work. I bet you'll like the result! I sure have when I've done it.

On 6/17/21 3:39 AM, Walter Bright wrote:
> On 6/16/2021 2:25 PM, Timon Gehr wrote:
>> Yes. This.
> 
> At last, Timon, we agree on something! You've made my day!

We agree on many things. Maybe I should point it out more often. :)

On Wednesday, 16 June 2021 at 13:17:41 UTC, Steven Schveighoffer wrote:
> I would support @trusted blocks, as long as we can have @system variables (DIP1035) and variables declared inside a @trusted block were implicitly @system.

That would be great if both reading and writing those local @system variables wouldn't compile in @safe only code. So it would require another @trusted block any time those variables were used. That could be the holy grail of supporting compiler checking of all @safe operations even in a function that does unsafe stuff.

On 6/18/2021 2:41 AM, Timon Gehr wrote:
> On 6/17/21 3:39 AM, Walter Bright wrote:
>> On 6/16/2021 2:25 PM, Timon Gehr wrote:
>>> Yes. This.
>>
>> At last, Timon, we agree on something! You've made my day!
> 
> We agree on many things. Maybe I should point it out more often. :)

<g>