Thread overview
[Issue 23140] Array!T where T is a shared class no longer works
Aug 03, 2022
Ruby The Roobster
Aug 03, 2022
Dlang Bot
Aug 03, 2022
Dlang Bot
Aug 08, 2022
RazvanN
Aug 10, 2022
Ruby The Roobster
Aug 15, 2022
Ruby The Roobster
Aug 30, 2022
Dlang Bot
August 03, 2022
https://issues.dlang.org/show_bug.cgi?id=23140

Ruby The Roobster <rubytheroobster@yandex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rubytheroobster@yandex.com

--- Comment #1 from Ruby The Roobster <rubytheroobster@yandex.com> ---
(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.).
> 

I'm currently working on a fix, and I've noticed the following:

While creating an Unshared template (https://forum.dlang.org/post/xigdpyblcgsyaawhywva@forum.dlang.org), and doing the following solved most of the problems:

```d
//...
struct Array(W) //Changed from struct Array(T)
if (!is(immutable W == immutable bool)) //Change 'T' to 'W'
{
    alias T = Unshared!W; //Fix https://issues.dlang.org/show_bug.cgi?id=23140
    //...
```

This doesn't fix the constructor for Array.

I still get the following error message:

```
E:\Programs\D\dmd2\windows\bin\..\..\src\phobos\std\container\array.d(650):
Error: none of the overloads of template
`std.container.array.Array!(shared(C)).Array.__ctor` are callable using
argument types `!()(C[])`
E:\Programs\D\dmd2\windows\bin\..\..\src\phobos\std\container\array.d(575):
   Candidates are: `__ctor(U)(U[] values...)`
E:\Programs\D\dmd2\windows\bin\..\..\src\phobos\std\container\array.d(605):
                   `__ctor(Range)(Range r)`
  with `Range = C[]`
  must satisfy the following constraint:
`       !is(Range == T[])`
```

> Three options here:
> 
> 1. Fix Array to cast away the shared when using these functions (a
> reasonable assumption)
> 2. Fix the druntime functions so they also accept `shared` pointers
> 3. close this bug as wontfix, and I'll have to work around it in the project
> I'm trying to compile (libasync)

--
August 03, 2022
https://issues.dlang.org/show_bug.cgi?id=23140

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #2 from Dlang Bot <dlang-bot@dlang.rocks> ---
@RubyTheRoobster created dlang/phobos pull request #8525 "fix issue 23140" fixing this issue:

- Fix issue 23140 - Array!T where T is a shared class no longer works

https://github.com/dlang/phobos/pull/8525

--
August 03, 2022
https://issues.dlang.org/show_bug.cgi?id=23140

--- Comment #3 from Dlang Bot <dlang-bot@dlang.rocks> ---
@RubyTheRoobster created dlang/phobos pull request #8526 "fix issue 23140" fixing this issue:

- Fix issue 23140 - Array!T where T is a shared class no longer works

https://github.com/dlang/phobos/pull/8526

--
August 08, 2022
https://issues.dlang.org/show_bug.cgi?id=23140

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #4 from RazvanN <razvan.nitu1305@gmail.com> ---
(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.

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

--
August 10, 2022
https://issues.dlang.org/show_bug.cgi?id=23140

--- Comment #5 from Ruby The Roobster <rubytheroobster@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)

--
August 15, 2022
https://issues.dlang.org/show_bug.cgi?id=23140

Ruby The Roobster <rubytheroobster@yandex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Ruby The Roobster <rubytheroobster@yandex.com> ---
The pull request has been merged.

--
August 30, 2022
https://issues.dlang.org/show_bug.cgi?id=23140

--- Comment #7 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/phobos pull request #8548 "merge stable" was merged into master:

- f293250cd8475d72acf583d3156382b73cf78339 by RubyTheRoobster:
  Fix issue 23140 - Array!T where T is a shared class no longer works

- 2023b271e560ab59cd6e5a9453331f5adf96f44b by RubyTheRoobster:
  Fix issue 23140 - Array!T where T is a shared class no longer works

- 36efa13efbd8a2882f6f999d900400b5515e39b4 by The Dlang Bot:
  Merge pull request #8526 from RubyTheRoobster/fix-23140

  fix issue 23140

  Signed-off-by: Dennis <dkorpel@users.noreply.github.com>
  Merged-on-behalf-of: Dennis <dkorpel@users.noreply.github.com>

https://github.com/dlang/phobos/pull/8548

--