how much "real-life" code can be marked @safe ?

[Steven Schveighoffer]

On 7/1/21 8:26 PM, someone wrote:
> ... just wondering:
> 
> I am writing pretty trivial code, nothing out of the ordinary, and 
> attempted to check how much of it could be marked safe ...

It should be quite a bit.

> 
> - Lots of tiny common library functions are pretty easy
> 
> - Getter/Setter properties are easy too
> 
> - almost all this() constructors are a no-go providing you do something 
> in-between with the parameters until you assign them back to the target 
> variables; eg: you have a char parameter (that you need to do something 
> with it) that needs to be assigned to a class/structure string member 
> variable and then it needs a cast ... but no castings are allowed with 
> @safe

This doesn't make a lot of sense, lots of constructors are safe.

And casting is OK as long as it's safe, including class downcasts.

> 
> But when you start attempting to declare @safe chunks of code that 
> actually DO things ... well, it seems end-of-the-story.

This is why you encapsulate the unsafe parts in @trusted functions.

The classic example is the posix `read` and `write` functions. The 
function `int read(int fd, void *data, int len)` is not safe, nor can it 
be trusted. But a trusted wrapper is possible: `@trusted int 
readSafe(int fd, ubyte[] data)`. Now all of a sudden, safe functions 
have more utility.

> 
> Declaring @safe void() main() {...} as I was advised in some previous 
> post (to avoid declaring @safe everywhere) is almost impossible unless 
> you are doing the hello world app.

The point is to mark main @safe, and then fix whatever things that 
aren't safe that it calls to provide a safe interface.

> 
> I would love to hear how you, I mean the community, approach code 
> safeness ?

Any function I want to make safe, I mark it as @safe. Then I fix the 
compiler complaints until it compiles (including functions that it 
calls), using as little @trusted code as possible.

-Steve