February 12
On Thursday, 8 February 2024 at 05:12:06 UTC, Paul Backus wrote:
> On Wednesday, 7 February 2024 at 22:00:49 UTC, Jonathan M Davis wrote:
>> [...]
>
> With -preview=dip1000 and -preview=systemVariables, it is possible to make pretty much any allocator @safe--although for some of them, the safety checking adds a little bit of runtime overhead.
>
> The main obstacle is that both of these -preview features are still very much unfinished, and will need a lot of work before they are ready to be used in real library code.
>
> By the way, one of the key techniques that makes this work is having the allocators wrap each void[] they return in a non-copyable struct, so that it can only be deallocated once. So you can probably understand why I'm so concerned about support for non-copyable types in Phobos v3. :)

What specifically would we need support for?

February 12

On Monday, 12 February 2024 at 17:00:01 UTC, Atila Neves wrote:

>

On Wednesday, 7 February 2024 at 21:26:51 UTC, jmh530 wrote:

>

On Wednesday, 7 February 2024 at 10:10:27 UTC, Atila Neves wrote:

>

[snip]

The problem with this approach, as C++ found out, is that Vector!(int, MyAlloc) is a different type from Vector!(int, YourAlloc). The way I got around that is by defaulting to a global allocator. This has its drawbacks as well of course, because now everything is a virtual call.

If you need to allocate or deallocate, then it's useful to treat them as separate types. Otherwise it's not.

alias MyVec = Vector(MyType, Mallocator);
void fun(MyVec vec) {
     // just before the curly brace, the elements and storage for them get deallocated.
}

I assume you mean alias MyVec = Vector!(MyType, Mallocator);.

I'm not completely sure I'm getting to the heart of what you're saying since your post is a bit sparse...but I'm doing my best.

Your fun function only works for MyVec, which depends on MyType and Mallocator. It isn't general across either types or allocators. It's kind of the essence of your complaint about C++ and treating Vector!(int, MyAlloc) and Vector!(int, YourAlloc) as different types, except you are pushing all the work downstream to functions. In other words, you have to have separate fun for all the different types and allocators you pass, and then have different allocation strategies for each. Multiply that across all the other functions.

If all the allocators are consistent with the interface from std.experimental.allocator, then you might be able to make the allocation more general. But, it becomes frustrating to rely on template aliases. The compiler can't see through them due to issue 1807 [1]. The more general approach is to use template constraints (see example below). The problem with the template constraint approach is that it leads to template bloat, which is why I suggested the alias this approach above.

Another approach would be to pass the allocator to the function instead of making it part of the type. The problem with this is that for some allocators you need to know what did the allocating in order to free it safely.

import std.stdio;

struct Vector(T, U) { T x; U y;}
alias MyVec = Vector!(double, int);
void fun(MyVec vec)
{
    writeln("works");
}
alias MyVec2(T) = Vector!(T, int);
void fun2(T)(MyVec2!T vec)
{
    writeln("works2");
}
void fun3(T)(T vec)
    if (is(T : Vector!(U, int), U))
{
    writeln("works3");
}

void main() {
    MyVec vec = MyVec(1.0, 1);
    fun(vec); // prints works
    //fun2(vec); //error
    fun2!double(vec); // prints works2
    fun3(vec); // prints works3
}

[1] https://issues.dlang.org/show_bug.cgi?id=1807

February 12
On Monday, 12 February 2024 at 17:07:21 UTC, Atila Neves wrote:
> On Thursday, 8 February 2024 at 05:12:06 UTC, Paul Backus wrote:
>> By the way, one of the key techniques that makes this work is having the allocators wrap each void[] they return in a non-copyable struct, so that it can only be deallocated once. So you can probably understand why I'm so concerned about support for non-copyable types in Phobos v3. :)
>
> What specifically would we need support for?

It's not really any specific thing; it's more that Phobos's general attitude towards non-copyable types needs to change.

Currently, there are a huge number of interfaces in Phobos that, in principle, could work with non-copyable types, but just don't, because no one ever thought of it or cared enough. Such interfaces include:

- Large portions of std.range and std.algorithm
- std.format in its entirety
- std.typecons.Tuple
- std.array.Appender
- etc.

From how widespread it is, it's clear that this is not an issue of specific bugs or design mistakes. It's a systemic problem in the way Phobos's code is written, tested, and reviewed.

The attitude that leads to this problem is exemplified by Jonathan M. Davis's comments in the "Range Redesign" thread [1], but I do not want to single him out. Every single one of us who writes and reviews code for Phobos, and allows PRs to be merged that fail to handle non-copyable types, is a contributor to the problem (including myself!).

If we're going to fix this, whoever's leading the development of Phobos V3 (you? Adam Wilson?) needs to make a policy-level decision that no PR gets merged unless it either supports non-copyable types, or has a good reason not to.

[1]: https://forum.dlang.org/post/mailman.618.1705964882.3719.digitalmars-d@puremagic.com
February 13
On Monday, 12 February 2024 at 19:49:39 UTC, Paul Backus wrote:
> On Monday, 12 February 2024 at 17:07:21 UTC, Atila Neves wrote:
>> On Thursday, 8 February 2024 at 05:12:06 UTC, Paul Backus wrote:
>>> By the way, one of the key techniques that makes this work is having the allocators wrap each void[] they return in a non-copyable struct, so that it can only be deallocated once. So you can probably understand why I'm so concerned about support for non-copyable types in Phobos v3. :)
>>
>> What specifically would we need support for?
>
> It's not really any specific thing; it's more that Phobos's general attitude towards non-copyable types needs to change.
>
> Currently, there are a huge number of interfaces in Phobos that, in principle, could work with non-copyable types, but just don't, because no one ever thought of it or cared enough. Such interfaces include:
>
> - Large portions of std.range and std.algorithm
> - std.format in its entirety
> - std.typecons.Tuple
> - std.array.Appender
> - etc.
>
> From how widespread it is, it's clear that this is not an issue of specific bugs or design mistakes. It's a systemic problem in the way Phobos's code is written, tested, and reviewed.

I see. This is an instance of a more general problem of "nasty types" that do "weird" things such as being uncopyable. Ideally we'd have one in Phobos just for testing and feed it to basically everything. FeepingCreature mentioned something like to me at DConf but I can't find it in github after googling.


February 13
On Tuesday, 13 February 2024 at 14:08:24 UTC, Atila Neves wrote:
> I see. This is an instance of a more general problem of "nasty types" that do "weird" things such as being uncopyable. Ideally we'd have one in Phobos just for testing and feed it to basically everything. FeepingCreature mentioned something like to me at DConf but I can't find it in github after googling.

If you want some examples to crib from, check out the unittests in std.sumtype. I've done my best to put every weird type I can think of in there. :)
February 13

On Monday, 12 February 2024 at 18:13:45 UTC, jmh530 wrote:

>

On Monday, 12 February 2024 at 17:00:01 UTC, Atila Neves wrote:

>
[...]

I assume you mean alias MyVec = Vector!(MyType, Mallocator);.

I'm not completely sure I'm getting to the heart of what you're saying since your post is a bit sparse...but I'm doing my best.

[...]

My point is that things going out of scope can trigger deallocations. You're right that passing the allocator is error-prone. That's why automem, unlike C++'s smart pointers, doesn't let you construct the thing and pass it in; it's more "tell me what you want and I'll construct it for you".

February 13
On Tuesday, 13 February 2024 at 15:27:16 UTC, Paul Backus wrote:
> On Tuesday, 13 February 2024 at 14:08:24 UTC, Atila Neves wrote:
>> I see. This is an instance of a more general problem of "nasty types" that do "weird" things such as being uncopyable. Ideally we'd have one in Phobos just for testing and feed it to basically everything. FeepingCreature mentioned something like to me at DConf but I can't find it in github after googling.
>
> If you want some examples to crib from, check out the unittests in std.sumtype. I've done my best to put every weird type I can think of in there. :)

Nice! Now we "just" have to move them somewhere common (so that other Phobos modules don't depend on sumtype for no reason) and shove them down the rest of Phobos. Somehow.
1 2 3 4 5 6 7 8 9
Next ›   Last »