[Issue 23140] Array!T where T is a shared class no longer works

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Aug 10 14:52:55 UTC 2022


https://issues.dlang.org/show_bug.cgi?id=23140

--- Comment #5 from Ruby The Roobster <rubytheroobster at yandex.com> ---
(In reply to RazvanN from comment #4)
> (In reply to Steven Schveighoffer from comment #0)
> > I'm not sure it should have ever worked, but I'm also wondering why this
> > cannot be made to work.
> > 
> > Prior to 2.099.0, the following code compiled:
> > 
> > ```d
> > import std.container : Array;
> > shared class C {}
> > 
> > Array!C arr;
> > ```
> > 
> > But it no longer does. The reason is because of the fix for
> > https://issues.dlang.org/show_bug.cgi?id=22515. Now, a C is actually typed
> > as `shared(C)`, and it does not implicitly cast to `const void *` (used by
> > GC functions and pureFree, etc.).
> > 
> > Three options here:
> > 
> > 1. Fix Array to cast away the shared when using these functions (a
> > reasonable assumption)
> 
> From my perspective, it should be illegal to cast away the sharedness if an
> aggregate was defined `shared struct/class T` (this could be extended to any
> type qualifier, but let's just stick to shared). If the user opted to define
> the aggregate as such, I think it is reasonable to assume that any use of
> such an object is going to violate the definition of the object.
> 
> > 2. Fix the druntime functions so they also accept `shared` pointers
> 
> In my opinion, this is the most sensible approach.

Or you could just cast to void* in the function call (which doesn't break
free/pureFree)

> 
> > 3. close this bug as wontfix, and I'll have to work around it in the project
> > I'm trying to compile (libasync)

--


More information about the Digitalmars-d-bugs mailing list