Simplification of @trusted

[Ola Fosheim Grøstad]

On Thursday, 17 June 2021 at 13:54:06 UTC, ag0aep6g wrote:
> 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.

This is way too constraining.

At the very least it should accept a Phobos ownership-transfer 
wrapper where you can an obtain a buffer as a one-time transfer. 
Meaning, if you try to obtain it, it is moved out of the wrapper.

That would be perfectly 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?

Let us assume filebuffer is just a wrapper that transfers 
ownership. It prevents borrowing and ownership can only be 
transferred once. This is fully encapsulated. That is the 
invariant for the filebuffer.

Yet, as it only is an invariant, you would need to reallocate the 
buffer then stream over the filebuffer into your own buffer 
according to the requirements you've been kind to point out to me.


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

I guess, but it is too simple. It is conceptually just `if 
(*ptr==0) return 0; return *(++ptr);`.

For the @trusted to rely on this it has to know that it has 
unique access to the buffer.

The filebuffer object guarantees this, but it is an invariant, it 
cannot be checked by the language.

As a consequence you trigger completely pointless copying.

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

I am sure that it will be used as intended in Phobos, or at least 
that this is achievable, but not in the kind of libraries that 
would be targeting games and such.

And well, one selling point for D could be that it is possible to 
write games in a _safer_ environment than C++...

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

Well, then nobody else will either. :-/