Skip to content

Conversation

@wilzbach
Copy link
Contributor

@wilzbach wilzbach commented Apr 29, 2016

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.


/// Ditto
T[] makeArray(T, Allocator, R)(auto ref Allocator alloc, R range)
auto makeArray(T = void, Allocator, R)(auto ref Allocator alloc, R range)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not T = ElementType!Range?

Copy link
Contributor Author

@wilzbach wilzbach Apr 29, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@wilzbach wilzbach force-pushed the infer_type_for_make_array_with_ranges branch 3 times, most recently from d099a4e to 6c2b8ca Compare April 29, 2016 15:18
@wilzbach
Copy link
Contributor Author

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

/// Ditto
Unqual!(ElementType!R)[] makeArray(Allocator, R)(auto ref Allocator alloc, R range)
if (isInputRange!R)
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.primitives

@wilzbach wilzbach force-pushed the infer_type_for_make_array_with_ranges branch from 6c2b8ca to c95b820 Compare April 29, 2016 15:29
@wilzbach wilzbach changed the title infer elementtype for ranges in makeArray,makeSlice infer elementType for ranges in makeArray,makeSlice Apr 29, 2016
@PetarKirov
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

MetaLang commented May 3, 2016

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

@wilzbach
Copy link
Contributor Author

wilzbach commented May 6, 2016

@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

Unqual!(ElementType!R)[] makeArray(Allocator, R)(auto ref Allocator alloc, R range)
if (isInputRange!R)
{
import std.range.primitives;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use ElementEncodingType?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

@PetarKirov PetarKirov Jun 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

@andralex
Copy link
Member

preapproved once nits are looked at

@wilzbach wilzbach force-pushed the infer_type_for_make_array_with_ranges branch 2 times, most recently from d61f087 to c44b282 Compare June 19, 2016 21:40
@wilzbach
Copy link
Contributor Author

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

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

@PetarKirov
Copy link
Member

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
Copy link
Contributor

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

}

/// Ditto
Unqual!(ElementType!R)[] makeArray(Allocator, R)(auto ref Allocator alloc, R range)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

&& !infinityRange!R

@wilzbach wilzbach force-pushed the infer_type_for_make_array_with_ranges branch 3 times, most recently from 71c87b2 to 7bcd92f Compare July 21, 2016 17:09
}

for (; !range.empty; range.popFront, ++i)
import std.conv : emplace;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

@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
Copy link
Member

9il commented Jul 22, 2016

LGTM

@9il
Copy link
Member

9il commented Jul 22, 2016

Travis fails, fix/rebase please

@schveiguy
Copy link
Member

@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 wilzbach force-pushed the infer_type_for_make_array_with_ranges branch from 7bcd92f to f35efe4 Compare July 22, 2016 23:21
@wilzbach
Copy link
Contributor Author

Travis fails, fix/rebase please

Done. Should be passing now.

@9il
Copy link
Member

9il commented Jul 23, 2016

Auto-merge toggled on

@9il 9il merged commit 9a00cb5 into dlang:master Jul 23, 2016
@wilzbach wilzbach deleted the infer_type_for_make_array_with_ranges branch August 31, 2016 08:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants