Trying to use Mir ion, its a perfect example of the failure of D's attribute system

H. S. Teoh hsteoh at qfbox.info
Fri Jan 20 03:19:54 UTC 2023


On Thu, Jan 19, 2023 at 05:45:31PM -0800, Walter Bright via Digitalmars-d wrote:
> On 1/19/2023 5:14 AM, Adam D Ruppe wrote:
> > So if someone in a library wrote
> > 
> > void process(void delegate() userData) @nogc {}
> > 
> > it is going to force userData to be nogc regardless of their own
> > desires.
> 
> If process calls userData, then that is as it should be. If userData
> is just being "passed through" and not called, then the easiest
> workaround is to cast it to something innocuous, or use a union.

This is a flaw in the language: there is no way to express that
`process`'s attributes inherit from the passed-in delegate.  This has
been a pain point for years.

The basic idea is that we want to ensure that the body of `process`,
aside from the call(s) to userData, is pure/@nogc/@safe/etc., but we
don't want to prevent the caller from passing an impure/GC/@system/etc.
delegate (because it doesn't matter to the internal workings of
`process`).  This makes `process` usable from both GC and @nogc code: if
the caller is @nogc, then it must pass in a @nogc delegate.  But if the
caller is GC allocating, then an allocating delegate is permitted, since
the caller is already non- at nogc so a non- at nogc delegate will not change
anything.

If we don't do it this way, there will always be a case that doesn't
work.  If we make the delegate parameter @nogc, then non- at nogc code will
not be able to pass in a delegate that GC-allocates.  If OTOH we try to
be inclusive and make the delegate parameter unmarked, then @nogc code
will not be able to call `process`.  The only workaround in this case is
to invent `processWithGC` and `processWithNoGC` (because we cannot
overload on @nogc/non- at nogc) with identical function bodies.  This is a
waste, since the function bodies can be merged without changing any
semantics at all.

The same argument applies to the other attributes: pure, @safe, nothrow,
etc..


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter


More information about the Digitalmars-d mailing list