I rely a lot on std.experimental.alloctor for my "game engine". I have just finished creating my own version for "Algebraic" and I want to disable to default construction as it would make no sense.

I have also created my own containers, the problem is that I can not use my version of "Algebraic" in any of my containers because all of them are using std.experimental.alloctor.makeArray which can not be used with non default constructible types.

While I don't want to have any default constructed type of Algebraic, I really don't care for uninitialized values that I will never use anyway.

I am sure there is a workaround with unions but it would be nice if makeArray/expandArray would just support non default constructible types.

Thoughts?

On 6/3/16 7:47 AM, maik klein wrote:
> I rely a lot on std.experimental.alloctor for my "game engine". I have
> just finished creating my own version for "Algebraic" and I want to
> disable to default construction as it would make no sense.
>
> I have also created my own containers, the problem is that I can not use
> my version of "Algebraic" in any of my containers because all of them
> are using std.experimental.alloctor.makeArray which can not be used with
> non default constructible types.
>
> While I don't want to have any default constructed type of Algebraic, I
> really don't care for uninitialized values that I will never use anyway.
>
> I am sure there is a workaround with unions but it would be nice if
> makeArray/expandArray would just support non default constructible types.
>
> Thoughts?

Looks like a bug. Do you have a short repro? -- Andrei

On Friday, 3 June 2016 at 11:52:52 UTC, Andrei Alexandrescu wrote:
> On 6/3/16 7:47 AM, maik klein wrote:
>> I rely a lot on std.experimental.alloctor for my "game engine". I have
>> just finished creating my own version for "Algebraic" and I want to
>> disable to default construction as it would make no sense.
>>
>> I have also created my own containers, the problem is that I can not use
>> my version of "Algebraic" in any of my containers because all of them
>> are using std.experimental.alloctor.makeArray which can not be used with
>> non default constructible types.
>>
>> While I don't want to have any default constructed type of Algebraic, I
>> really don't care for uninitialized values that I will never use anyway.
>>
>> I am sure there is a workaround with unions but it would be nice if
>> makeArray/expandArray would just support non default constructible types.
>>
>> Thoughts?
>
> Looks like a bug. Do you have a short repro? -- Andrei

import std.experimental.allocator;
struct Foo{
    @disable this();
}
auto foos = theAllocator.makeArray!Foo(100);

Error messsage:

../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/package.d(576,34): Error: variable std.experimental.allocator.uninitializedFillDefault!(Foo).uninitializedFillDefault.t default construction is disabled for type immutable(Foo)
../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/package.d(612,36): Error: template instance std.experimental.allocator.uninitializedFillDefault!(Foo) error instantiating
source/breeze/util/algebraic.d(91,43):        instantiated from here: makeArray!(Foo, IAllocator)

On 06/03/2016 01:47 PM, maik klein wrote:
> I rely a lot on std.experimental.alloctor for my "game engine". I have just finished creating my own version for "Algebraic" and I want to disable to default construction as it would make no sense.
> 
> I have also created my own containers, the problem is that I can not use my version of "Algebraic" in any of my containers because all of them are using std.experimental.alloctor.makeArray which can not be used with non default constructible types.
> 
> While I don't want to have any default constructed type of Algebraic, I really don't care for uninitialized values that I will never use anyway.
> 
> I am sure there is a workaround with unions but it would be nice if makeArray/expandArray would just support non default constructible types.
> 
> Thoughts?

Do you refer specifically to `makeArray` family of helpers or something
more than that? Basic allocator interface is untyped and doesn't do any
construction, i.e.
https://dlang.org/phobos/std_experimental_allocator.html#.CAllocatorImpl.allocate
- even plain `make` helper
(https://dlang.org/phobos/std_experimental_allocator.html#.make) accepts
optional list of arguments for non-default construction.

For `makeArray` I don't see how it can possibly be fixed. Lack of default construction means no valid initial value for array elements, period. I don't know if you can declare plain static array of such structs but you shouldn't be able to.

Note that `makeArray` also accepts optional `init` argument to be used instead of default constructed state.

On 6/3/16 7:57 AM, maik klein wrote:
> On Friday, 3 June 2016 at 11:52:52 UTC, Andrei Alexandrescu wrote:
>> On 6/3/16 7:47 AM, maik klein wrote:
>>> I rely a lot on std.experimental.alloctor for my "game engine". I have
>>> just finished creating my own version for "Algebraic" and I want to
>>> disable to default construction as it would make no sense.
>>>
>>> I have also created my own containers, the problem is that I can not use
>>> my version of "Algebraic" in any of my containers because all of them
>>> are using std.experimental.alloctor.makeArray which can not be used with
>>> non default constructible types.
>>>
>>> While I don't want to have any default constructed type of Algebraic, I
>>> really don't care for uninitialized values that I will never use anyway.
>>>
>>> I am sure there is a workaround with unions but it would be nice if
>>> makeArray/expandArray would just support non default constructible
>>> types.
>>>
>>> Thoughts?
>>
>> Looks like a bug. Do you have a short repro? -- Andrei
>
> import std.experimental.allocator;
> struct Foo{
>      @disable this();
> }
> auto foos = theAllocator.makeArray!Foo(100);
>
> Error messsage:
>
> ../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/package.d(576,34):
> Error: variable
> std.experimental.allocator.uninitializedFillDefault!(Foo).uninitializedFillDefault.t
> default construction is disabled for type immutable(Foo)
> ../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/package.d(612,36):
> Error: template instance
> std.experimental.allocator.uninitializedFillDefault!(Foo) error
> instantiating
> source/breeze/util/algebraic.d(91,43):        instantiated from here:
> makeArray!(Foo, IAllocator)

That should be fixable, please submit to bugzilla. Thanks! -- Andrei

On Friday, 3 June 2016 at 12:16:54 UTC, Andrei Alexandrescu wrote:
> On 6/3/16 7:57 AM, maik klein wrote:
>> On Friday, 3 June 2016 at 11:52:52 UTC, Andrei Alexandrescu wrote:
>>> On 6/3/16 7:47 AM, maik klein wrote:
>>>> [...]
>>>
>>> Looks like a bug. Do you have a short repro? -- Andrei
>>
>> import std.experimental.allocator;
>> struct Foo{
>>      @disable this();
>> }
>> auto foos = theAllocator.makeArray!Foo(100);
>>
>> Error messsage:
>>
>> ../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/package.d(576,34):
>> Error: variable
>> std.experimental.allocator.uninitializedFillDefault!(Foo).uninitializedFillDefault.t
>> default construction is disabled for type immutable(Foo)
>> ../../.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/package.d(612,36):
>> Error: template instance
>> std.experimental.allocator.uninitializedFillDefault!(Foo) error
>> instantiating
>> source/breeze/util/algebraic.d(91,43):        instantiated from here:
>> makeArray!(Foo, IAllocator)
>
> That should be fixable, please submit to bugzilla. Thanks! -- Andrei

Thanks, I opened an issue here https://issues.dlang.org/show_bug.cgi?id=16117

I just used makeArray because it was just so convenient to use but I guess I could also switch to the untyped interface if this proves to be a blocker.

On Friday, June 03, 2016 14:01:57 Dicebot via Digitalmars-d wrote:
> For `makeArray` I don't see how it can possibly be fixed. Lack of default construction means no valid initial value for array elements, period. I don't know if you can declare plain static array of such structs but you shouldn't be able to.

Presumably, what he wants is the equivalent of std.array.uninitializedArray but with allocators. It's not the sort of thing that I'd recommend doing normally, since you're at a high risk of shooting yourself in the foot, but it should be possible.

Actually, it's stuff like that and emplace that makes invariants pretty much useless, since opAssign checks the invariant before it's called, meaning that you end up with garbage being checked against the invariant before you give it a proper value. Unfortunately, I couldn't convince Walter that opAssign should stop checking the invariant. :(

But while stuff like initializing to void should generally be avoided, it _is_ possible, including with arrays.

- Jonathan M Davis

On 6/3/16 8:24 AM, maik klein wrote:
> Thanks, I opened an issue here
> https://issues.dlang.org/show_bug.cgi?id=16117
>
> I just used makeArray because it was just so convenient to use but I
> guess I could also switch to the untyped interface if this proves to be
> a blocker.

Great, thanks. That seems to point at an issue in emplace. Surprisingly this recent work by Walter should be able to help: https://github.com/dlang/dmd/pull/5830. It makes "union" essentially a pure layout design tool. -- Andrei