Add ArrayElementType template (fixes issue 5061)

[denis-sh]

This supersedes accidentally merged and then reverted Pull #664.
Issue 5061 - std.traits.arrayTarget

See pull 664 comments for information/opinions.

[shoo]

Does not std.traits.ForeachType/std.range.ElementType fit the purpose?

[denis-sh]

@shoo, see pull 664 comments please.
And you just shown that this pull is needed because people not dealing with ranges doesn't fill the difference between ElementType and ElementEncodingType.

[jmdavis]

I still think that this is pointless code duplication. ElementEncodingType does this already. Yes, it's an annoyingly long name, but we already have it, and it works. This is effectively just an alias for it, which we generally try to avoid in Phobos. I'll let some other Phobos devs weigh in on it rather than simply closing it, but I'm definitely against this.

[alexrp]

Is there any actual reason ElementEncodingType cannot be used instead?

[denis-sh]

Is there any actual reason ElementEncodingType cannot be used instead?

My opinion is in pull 664 comments. I can only add this:
Why are there writeln, writef, and writefln is we already have write? And why there are free functions if we already have stdout.write? Same for read* functions.

[alexrp]

But those functions are there to actually make code easier to write, i.e. you have to do fewer calls in your code. This just seems like (effectively) an alias of ElementEncodingType.

[denis-sh]

But those functions are there to actually make code easier to write,

arrayTarget is here to make code easier to read (more self-documented).

i.e. you have to do fewer calls in your code.

I see same calls count in every case: writeln(str), write(str, "\n"), stdout.write(str, "\n").

This just seems like (effectively) an alias of ElementEncodingType.

More precisely it is ElementEncodingType!T if isArray!T.

[alexrp]

arrayTarget is here to make code easier to read (more self-documented).

I don't know what that is...

I see same calls count in every case: writeln(str), write(str, "\n"), stdout.write(str, "\n").

Let's not get pedantic (where's writef?). I think you know what my point is: Simplifying typical programming tasks.

But I think I now see your point: You want this trait because it only allows passing array types. While I can't think of idiomatic D code that wouldn't allow both range and array types in templatized code, I suppose it is reasonable to have this trait here for consistency if nothing else.

[denis-sh]

I don't know what that is...
You want this trait because it only allows passing array types

Template code is rather difficult in D and it often not obvious what type can be used in particular place. And if you see ArrayElementType!T you understand that T is an array. That is what I call more self-documented code.

While I can't think of idiomatic D code that wouldn't allow both range and array types in templatized code

See this pull diff for examples in Phobos.

[andralex]

I appreciate the arguments in favor of adding an ArrayElementType. However, ElementEncodingType is adequate (albeit unintuitively named) and I couldn't get convinced by the arguments involving precedents. I will close this now. Thanks for the contribution, and let's focus on the more meaty ones.

[DmitryOlshansky]

Do I get the timing right in the github logs?
Meaning that this one was closed 3 months ago and the 2 dependent pull were opened 2 months later (i.e. around a month ago)...
@denis-sh Did you specifically made you subsequent pulls depend on the already rejected one?
What was the point then?

[denis-sh]

Did you specifically made you subsequent pulls depend on the already rejected one?

Yes.

What was the point then?

As I disagree with rejecting of this pull and I always use ArrayElementType in my code and don't want to make my code uglier and less readable for phobos pulls.