named arguments, string interpolation, please stop.

H. S. Teoh hsteoh at qfbox.info
Fri Jan 12 04:47:44 UTC 2024


On Fri, Jan 12, 2024 at 03:13:58AM +0000, Guillaume Piolat via Digitalmars-d wrote:
> On Friday, 12 January 2024 at 01:21:32 UTC, H. S. Teoh wrote:
> > 
> > The only way a library author can deal with this mess is (1) write
> > in the most restricted language subset, i.e., betterC + @nogc, so
> > that it's usable by everybody. But the GC crowd will be unlikely to
> > use it, because it will lack the conveniences they're accustomed to,
> > the API will have manual memory management paraphrenalia that
> > doesn't fit well with the rest of user code. Plus this is also a
> > much higher bar for the library author, so you're further limiting
> > the already small number of people who are writing D libraries.  Or
> > (2) be opinionated and write a GC-using library, in which case the
> > betterC / @nogc people won't use it.  Either alternative leads to
> > ecosystem fragmentation. Or write a @nogc library but the betterC
> > people won't use it.  Etc..
> > 
> 
> Interesting post thanks. Describes the situation very well.
> I think more escape hatches (@localnogc?) may help with the delegate
> situation you related.

Escape hatches is not the answer.  What we need is (1) a consistent way
of enabling/disabling an attribute, and (2) a way of treating them as
first-class citizens, i.e., be able to express "this delegate's
attributes is equal to the attributes of the parent function".  Timon
already described this, I won't repeat the details.


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye


More information about the Digitalmars-d mailing list