named arguments, string interpolation, please stop.

[Jonathan M Davis]

On Thursday, January 11, 2024 3:17:05 PM MST Timon Gehr via Digitalmars-d 
wrote:
> On 1/11/24 22:37, Walter Bright wrote:
> > On 1/11/2024 1:18 PM, DrDread wrote:
> >> this is discarding the use case that you want to mark only parts of
> >> your codebase nogc, but enforce it'S really nogc. we do use some
> >> realtime threads, but the rest off the app is @gc.
> >
> > This subthread suggests to me that the problem with @nogc is it works.
> > ...
>
> It does not work. There are two options:
>
> - Mark the function and callback `@nogc`, then GC users cannot use your
> library.
> - Mark the function and callback not `@nogc`, then `@nogc` users cannot
> use your library.
>
> There are two options and both are wrong. There is no right answer
> except to accept that `@nogc` actually does not work for library
> writers, and neither do the other attributes.

Yeah, to an extent, the problem can be solved with templates, but that only
works if the attributes of the library code depend entirely on the template
arguments, and it becomes _very_ easy to break other people's code when
changing the implementation by accidentally changing which attributes are
inferred.

Once the code isn't templated, you're either restricting what the library
can do with its implementation by using attributes on it which then prevent
you from being able to refactor the code in a way that doesn't work with
those attributes - or you're restricting what the user code can do with your
library, because they don't support one or more attributes that they
require. Either way, the existance of those attributes restricts what can be
done with your library regardless of which set of attributes you end up
using.

Another way to look at the problem is that many of these attributes are
effectively leaking the implementation details of your library. If you can
mark something as const or pure or @nogc, etc. then that says something
about what your library is currently doing. And because the code using your
library then potentially relies on those attributes being there, you then
can't change your implementation, because those details leaked through the
API.

- Jonathan M Davis