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