infer elementType for ranges in makeArray,makeSlice

[wilzbach]

As discussed earlier, it's possible to infer the ElementType for makeArray with Ranges.
Even better we can keep full compatibility and make this feature opt-in - is anyone against this?

tl;dr: let's allow the variant b! (a is still possible)

auto a = alloc.makeArray!long([5, 42]);
auto b = alloc.makeArray([5, 42]);

Ping @9il @andralex

edit: attached https://issues.dlang.org/show_bug.cgi?id=16450 to it.

[9il]

Why not T = ElementType!Range?

[wilzbach]

I would prefer that, but

1. this might break compatibility (which might be okay because it's experimental)
2. removes the feature to use a different type

[9il]

auto makeArray(T = ElementType!R, Allocator, R)
1 and 2. really?

[wilzbach]

thanks to @9il helpful I removed T = void and replaced it with an additional overload without T.

[9il]

.primitives

[PetarKirov]

I also prefer Ilya's version:
auto makeArray(T = ElementType!R, Allocator, R)

1. Doesn't break the API.
2. Still allows the user to specify the type manually.

[wilzbach]

auto makeArray(T = ElementType!R, Allocator, R)

I would prefer that too, but unfortunately D isn't that smart. It yields R is not defined.

[MetaLang]

@wilzbach that should work. It may be a possible bug with template argument type deduction.

[wilzbach]

@wilzbach that should work. It may be a possible bug with template argument type deduction.

@MetaLang AFAIK it's a missing feature, which would be awesome to have!
See Issue 12433

[andralex]

Use ElementEncodingType?

[wilzbach]

ElementEncodingType:

    static if (is(StringTypeOf!R) && is(R : E[], E))
        alias ElementEncodingType = E;
    else
        alias ElementEncodingType = ElementType!R

ElementType:

    static if (is(typeof(R.init.front.init) T))
        alias ElementType = T;
    else
        alias ElementType = void;

... where is the difference?

[PetarKirov]

ElementType!(char[]) == dchar
ElementEncodingType!(char[]) == char

(Because R.init.front.init is dchar for narrow strings.)

[andralex]

preapproved once nits are looked at

[wilzbach]

(Because R.init.front.init is dchar for narrow strings.)

Ah auto-decoding :S
Thanks for the explanation @ZombineDev!
(Rebased)

[PetarKirov]

No problem :)

Maybe not directly related to your PR, but do you happen to know what will makeArray return if the elements of the range are classes - an array of references to class instances or the actual array where the objects were allocated and emplaced?

[JackStouffer]

Ping @9il, I think this can be merged now

[9il]

&& !infinityRange!R

[wilzbach]

we need the special case for narrow strings & as we already have the special case, using it for arrays will be faster too (see e.g. #4265)

[wilzbach]

@9il addressed your comments - you were correct: strings are evil :S
I hope the special-casing I inserted is correct.

@wilzbach please add replaceArrayWithPointer for each function in the module and fix its name in the docs for sliced

Will do this in a separate PR ;-)

[9il]

LGTM

[9il]

Travis fails, fix/rebase please

[schveiguy]

@9il FYI, you can log in your GH user to travis to force a rebuild (as a dlang member). Just figured this out recently. However, in this case, I don't think that will help, as there is an actual issue.

[wilzbach]

Travis fails, fix/rebase please

Done. Should be passing now.

[9il]

Auto-merge toggled on