Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
August 03 [Issue 23140] Array!T where T is a shared class no longer works | ||||
---|---|---|---|---|
| ||||
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 [Issue 23140] Array!T where T is a shared class no longer works | ||||
---|---|---|---|---|
| ||||
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 [Issue 23140] Array!T where T is a shared class no longer works | ||||
---|---|---|---|---|
| ||||
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 -- |
2 days ago [Issue 23140] Array!T where T is a shared class no longer works | ||||
---|---|---|---|---|
| ||||
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) -- |
16 hours ago [Issue 23140] Array!T where T is a shared class no longer works | ||||
---|---|---|---|---|
| ||||
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) -- |
Copyright © 1999-2021 by the D Language Foundation