On 15.06.22 12:49, Dukc wrote:
> This would be outright poison for a stable API or ABI of a library, probably including ARSD. All your public functions have attributes added to them under your nose, and then you cannot change them without breaking client code because it depends on those attributes you did not intend to add.

This.

For this to work, there would need to be some way of saying that, for instance, you don't want your function inferred @nogc, even it might be in its current implementation (which btw can be just returning "false" or throwing "Not implemented yet").

Why? Because you want the actual interface to leave open the possibility of needing to allocate later, and if your library isn't overall @nogc, why would you want to lock just one function as @nogc?

On Wednesday, 15 June 2022 at 10:49:13 UTC, Dukc wrote:
> This would be outright poison for a stable API or ABI of a library, probably including ARSD. All your public functions have attributes added to them under your nose, and then you cannot change them without breaking client code because it depends on those attributes you did not intend to add.

My view of this (which I need to write about in more detail in the blog, but I have 1,000 more lines of code to translate for work..... by tomorrow...... yeah im not gonna make the deadline but still wanna get as close as i can, so blog on hold for a bit) is that the explicit attributes are all that'd count for breakage, and the inferred ones are specifically subject to change at any time and people shouldn't rely on them. The auto-generated .di file might list it, but the documentation absolutely would not.

I suppose some users might want to statically guarantee they are only using the stable published interface instead of the unstable inferred one, and that would be a bit tricky to declare given the attributes are part of the abi too. That's one of the things that needs more consideration.


> Even in a top-level application it happens every now and then that I intentionally want to disable some attributes from a function.

It is obvious to me that everything that can be turned on needs to be able to be turned off.

tbh it is one if the biggest embarrassments of the attribute soup process we have right now that there STILL isn't a `@gc` or `impure` or whatever after all these years. Even the lowest hanging fruit out of this mess is in limbo.

On 6/14/22 04:39, Steven Schveighoffer wrote:
> 
> They are mostly marked @system, with a smattering of @safe and @trusted.
> 
> I'll tell you what, I'll do a *whole file* at a time `winsock32.d` ...
> 
> OK, I did it in less than 10 minutes.
> 
> https://github.com/dlang/druntime/pull/3839

There is a post-merge review of that pull request that points out that two of the functions cannot be `@trusted`. It seems in the current version of druntime in DMD master [1], they are still `@trusted`. (I would have commented on the pull request, but it is now archived.)

[1] https://github.com/dlang/dmd/blob/master/druntime/src/core/sys/windows/winsock2.d

I don't know much about windows sockets, so I am not sure what is the best way to fix this. I guess for `inet_ntoa` we should just remove @trusted. For `getprotobynumber`, I am not sure if we should just remove @trusted or if it is sufficient to mark the return value `const` (it seems like it might not be. Given that it says windows sockets will return pointers pointing to stuff it has allocated internally, it might also deallocate it internally at a later point?)

On 13.11.22 17:06, Steven Schveighoffer wrote:
> 
> When I did the first PR, I did not focus enough on the return values.
> 
> https://github.com/dlang/dmd/pull/14639

Thank you! :)