Simplification of @trusted

[ag0aep6g]

On 17.06.21 14:52, Ola Fosheim Grøstad wrote:
> When you ask for the next lexeme the lexer advances a pointer, if it 
> hits a zero character it stops advancing.
> 
> For this to be @trusted, by the safe-requirements, the lexer cannot 
> accept a filebuffer it has not allocated itself, as that makes it 
> possible for external code to overwrite the zeros.

That's right. An @trusted function cannot ever advance a pointer it 
received from the outside. It can only assume that the pointer can be 
dereferenced.

[...]
> The lexer should only require that the filebuffer invariant of unique 
> ownership and no borrowed pointers to hold. Then the lexer can add the 
> zero-character at the end of the buffer and it will be @safe.

You're losing me. You wrote that the lexer advances a pointer to a 
"character". I figure that means it has a `char*` parameter. What's a 
filebuffer? If it's a struct around a `char*`, why is the lexer 
manipulating the pointer directly instead of calling some method of the 
filebuffer?

An example in code (instead of descriptions) would go a long way.

[...]
> I don't think this is enough to prevent @safe code from tripping up 
> @trusted code as it would prevent many interesting ADTs from being 
> implemented efficently. Meaning, you would have to restrict yourself to 
> @safe practices (like bounds checks).

I'm sure many interesting types are not compatible with @safe/@trusted.

DIP 1000, Walter's @live experiments, and @system variables (DIP 1035 
[1]) might enable some more. The ideas in this thread might go 
somewhere, too.

[...]
> Ok, but it is not _realistic_ to think that D users will not write code 
> that they think is _good enough_ for their purpose. Since there is no 
> way to verify that they  adhere to idealistic principles, it won't happen.

I think there's almost a consensus that @trusted isn't quite good 
enough, exactly because no one can be bothered to use it as intended. 
That's why the incremental improvements mentioned above are being worked 
on. I don't think anyone is working on redesigning (or reinterpreting) 
the whole thing from the ground up. And I would expect strong push-back 
from Walter if someone tried.

> So, you can get Phobos to adhere to it, but basically no other libraries 
> will. And applications will most certainly make choices on a 
> case-by-case evaluation.

Phobos isn't even close to adhering to it. Yes, that's a problem.


[1] https://github.com/dlang/DIPs/blob/master/DIPs/DIP1035.md