On Friday, 30 January 2015 at 14:47:22 UTC, Andrei Alexandrescu wrote:

> Please advise.
>
>
> Andrei

+1
D's syntax is already big enough, if anything it needs reduced.

On 1/30/15 9:01 AM, Kenji Hara via Digitalmars-d wrote:
> 2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>>:
>
>     This version of staticArray allows the user to (optionally) specify
>     the element type.
>
>
> How the API can replace following declaration with ?
>
> auto[$][][$] = [
>      [[1,2]],
>      [[3,4], [5,6]],
>      [[7,8], [9,10], [11,12]],
> ];

This is interesting, and something we might get behind if it has general power. I'll note that partial deduction with "auto" is done in C++ and occasionally useful.

We should definitely support "const[] a1 = [1, 2, 3];" regardless of the general decision about [$].

Where I have more difficulty is understanding how e.g. matching may help in a function call context, or how it generalizes beyond inferring sizes for statically-sized arrays (which I'd say is a rather dull category of cases).

One other aspect is the more complex the array shape, the more awkward it becomes with library functions; however, the frequency of use or even necessity also decrease correspondingly.

One extra note - the original feature request https://issues.dlang.org/show_bug.cgi?id=481 was made in November 2006. At that time, common library artifacts such as CommonType did not exist and were at most a dream of the future; with what we have now doing everything needed takes a couple of lines. It looks like we've lost perspective.

Walter and I don't feel all too strongly about this so we wanted to gauge good signal from the dlang brass. We have a few roads from here:

1. Convince ourselves that [$] has current and future benefits that are larger than what library code can ensure reasonably, and do nothing - i.e. keep the feature starting with 2.067.

2. Release the feature but consider it experimental; don't document it, or mention it may be removed in future releases.

3. Release the feature and make it opt-in via a DIP (-dip=xxx) that would motivate it properly.

4. Undo the pull request at least for now, and get to the design table to make sure it's worth the added cost.

One road I want explicitly not taken is:

5. This feature is the first of a cornucopia of custom annotations for various related cases.

I am particularly worried by the near-instant use of this feature as a precedent for proposing more similar ones. We must stop that.


Andrei

On 1/30/15 9:57 AM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jan 30, 2015 at 06:47:22AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
>> As discussed in this forum, Kenji has authored
>> https://github.com/D-Programming-Language/dmd/pull/3615 which has been
>> recently merged.
>>
>> By this I am proposing we revert that decision, and quickly - before 2.067
>> is released lest we'll need to support it forever. Here's why.
>
> If it wasn't a good idea, I don't have a problem with reverting it, but
> what I'm wondering is, why raise the objection *now* rather than *months*
> ago when the PR was sitting in the queue idle? From the discussion on
> github, it appeared that the only objection against it was that Walter
> didn't like the syntax. Where were the arguments about it being a
> superfluous syntax change? Why raise the objections now rather than back
> then?
>
> I think we need to improve the process here. If a PR is not up to par or
> is a bad idea, or approval from Walter/Andrei is required, can we pretty
> please mark it as such beforehand? Rather than, as it would appear, let
> it sit there until someone merges it, only to parachute in after the
> fact to blast it to bits? (I know that's not the intention, but that's
> what it looks like, since I've lost count of how many months this
> particular PR was sitting in the queue with only minor nitpicks raised
> against it and no sign of imminent doom like it's made out to be now.)

I agree we could and should improve the process here. The way it's been handled has been quite inefficient.

You should know that I had pulled the request. So I was okay with it because I non-critically assumed it wasn't doable within the current language. I was obviously mistaken.

Such indecision/change of mind should not repeat often in the future. But the fact is it did happen this time, which is frustrating to everyone involved.


Andrei

On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven wrote:
> On 30/01/2015 16:53, Nick Treleaven wrote:
>> This version of staticArray allows the user to (optionally) specify the
>> element type.
>
> Actually, I'm having trouble implementing staticArray like that, perhaps there are compiler issues causing problems. Using this:
>
> T[len] staticArray(T, size_t len)(T[len] items)
> {
>     return items;
> }
>
> you would need to call it: staticArray([a, b, c]). UFCS doesn't seem to work, and I can't get the immutable or function array example to compile either (with the extra [brackets])...

That is such a ugly call. Consider this:

----
@nogc
@safe
T[n] s(T, size_t n)(auto ref T[n] values) pure nothrow {
	return values;
}
	
void main() {
	pragma(msg, typeof([1, 2, 3].s));
}
----
Something like staticArray([1, 2, 3]) is probably so ugly and way to long so that nobody new would like it or use it. We should consider the usability. int[$] looks nicer and is shorter. Nobody want to type ugly and long names instead.
Let look at staticArray([1, 2, 3]) as a new user: "I have to call a function with an array(whereby it is unclear to the new user if [1, 2, 3] is placed on the heap or not) and the result of this call is a static array? Why? Is it worth it? Should I use something cumbersome?"

That is why I'm either for the language feature or for something short like '[1, 2, 3].s'

And no, nobody want to write 'alias s = staticArray' every time again. Don't come with this counter please.

On 1/30/15 10:40 AM, Foo wrote:
> On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven wrote:
>> On 30/01/2015 16:53, Nick Treleaven wrote:
>>> This version of staticArray allows the user to (optionally) specify the
>>> element type.
>>
>> Actually, I'm having trouble implementing staticArray like that,
>> perhaps there are compiler issues causing problems. Using this:
>>
>> T[len] staticArray(T, size_t len)(T[len] items)
>> {
>>     return items;
>> }
>>
>> you would need to call it: staticArray([a, b, c]). UFCS doesn't seem
>> to work, and I can't get the immutable or function array example to
>> compile either (with the extra [brackets])...
>
> That is such a ugly call. Consider this:
>
> ----
> @nogc
> @safe
> T[n] s(T, size_t n)(auto ref T[n] values) pure nothrow {
>      return values;
> }
>
> void main() {
>      pragma(msg, typeof([1, 2, 3].s));
> }
> ----
> Something like staticArray([1, 2, 3]) is probably so ugly and way to
> long so that nobody new would like it or use it. We should consider the
> usability. int[$] looks nicer and is shorter. Nobody want to type ugly
> and long names instead.
> Let look at staticArray([1, 2, 3]) as a new user: "I have to call a
> function with an array(whereby it is unclear to the new user if [1, 2,
> 3] is placed on the heap or not) and the result of this call is a static
> array? Why? Is it worth it? Should I use something cumbersome?"
>
> That is why I'm either for the language feature or for something short
> like '[1, 2, 3].s'
>
> And no, nobody want to write 'alias s = staticArray' every time again.
> Don't come with this counter please.

The interesting thing is because of the tight overloading rules, "s" will only match statically-sized arrays. So it's okay to simply expose it as std.array.s without fear it might clash with other uses of the "s" symbol. Awesome. -- Andrei

On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu wrote:
> On 1/30/15 10:40 AM, Foo wrote:
>> On Friday, 30 January 2015 at 17:37:44 UTC, Nick Treleaven wrote:
>>> On 30/01/2015 16:53, Nick Treleaven wrote:
>>>> This version of staticArray allows the user to (optionally) specify the
>>>> element type.
>>>
>>> Actually, I'm having trouble implementing staticArray like that,
>>> perhaps there are compiler issues causing problems. Using this:
>>>
>>> T[len] staticArray(T, size_t len)(T[len] items)
>>> {
>>>    return items;
>>> }
>>>
>>> you would need to call it: staticArray([a, b, c]). UFCS doesn't seem
>>> to work, and I can't get the immutable or function array example to
>>> compile either (with the extra [brackets])...
>>
>> That is such a ugly call. Consider this:
>>
>> ----
>> @nogc
>> @safe
>> T[n] s(T, size_t n)(auto ref T[n] values) pure nothrow {
>>     return values;
>> }
>>
>> void main() {
>>     pragma(msg, typeof([1, 2, 3].s));
>> }
>> ----
>> Something like staticArray([1, 2, 3]) is probably so ugly and way to
>> long so that nobody new would like it or use it. We should consider the
>> usability. int[$] looks nicer and is shorter. Nobody want to type ugly
>> and long names instead.
>> Let look at staticArray([1, 2, 3]) as a new user: "I have to call a
>> function with an array(whereby it is unclear to the new user if [1, 2,
>> 3] is placed on the heap or not) and the result of this call is a static
>> array? Why? Is it worth it? Should I use something cumbersome?"
>>
>> That is why I'm either for the language feature or for something short
>> like '[1, 2, 3].s'
>>
>> And no, nobody want to write 'alias s = staticArray' every time again.
>> Don't come with this counter please.
>
> The interesting thing is because of the tight overloading rules, "s" will only match statically-sized arrays. So it's okay to simply expose it as std.array.s without fear it might clash with other uses of the "s" symbol. Awesome. -- Andrei

Exactly. ;)

On Friday, 30 January 2015 at 18:11:43 UTC, weaselcat wrote:
> On Friday, 30 January 2015 at 14:47:22 UTC, Andrei Alexandrescu wrote:
>
>> Please advise.
>>
>>
>> Andrei
>
> +1
> D's syntax is already big enough, if anything it needs reduced.

What would you remove?

On Friday, 30 January 2015 at 14:47:22 UTC, Andrei Alexandrescu wrote:
> As discussed in this forum, Kenji has authored https://github.com/D-Programming-Language/dmd/pull/3615 which has been recently merged.
>
> By this I am proposing we revert that decision, and quickly - before 2.067 is released lest we'll need to support it forever. Here's why.
>
> One simple litmus test for a new language feature is "it can't be done within the current language". That's a good yardstick; coupled with the importance of the task, it forms a compelling reason for adding the feature. There's nuance to that, e.g. it can be done but it's onerously difficult; or the feature is so frequently needed, dedicated language is warranted.
>
> The recent int[$] feature seems to fail that test. That feature, and in fact more, can be done trivially with library code:
>
> http://dpaste.dzfl.pl/f49a97e35974.
>
> In my opinion these particular features are not frequent enough to warrant dedicated syntax.

I'm somewhat neutral on [$], although I think it is useful. I like the partial type deduction feature and think we should keep that. It makes a lot of array declarations more concise, and subjectively, I think it feels like a natural extension of what D already does with auto.

I think if you showed someone auto declarations and then showed them something like auto[] arr = [...], their likely reaction would be "well of course that works". Although maybe I'm too familiar with D at this point and that's not the case at all.


> Furthermore, one other unpleasant aftermath of int[$] is that new syntax begets more new syntax. The proverbial ink was not yet dry on the #3615 merge when a new, new syntax was proposed in this forum, this time for statically-allocated statically-sized arrays. Far as I can tell the main argument is "you have to write longer code" without it.

If you're talking about Bearophile's proposed [1, 2]s syntax, he's been pushing that for a long time, possibly before [$].

On 1/30/15 12:33 PM, Meta wrote:
> I'm somewhat neutral on [$], although I think it is useful. I like the
> partial type deduction feature and think we should keep that. It makes a
> lot of array declarations more concise, and subjectively, I think it
> feels like a natural extension of what D already does with auto.
>
> I think if you showed someone auto declarations and then showed them
> something like auto[] arr = [...], their likely reaction would be "well
> of course that works". Although maybe I'm too familiar with D at this
> point and that's not the case at all.

Yah, that's nice but needs appropriate formalization. How about auto[auto] to ensure an associative array type, or Xyz!(auto, auto) to ensure template Xyz with exactly two arguments, or even auto!(auto) to match any template instantiated with one argument...?

It's just getting weird, and not very useful because it's impossible to associate names with those "auto"s. As I mentioned this is sometimes used in C++ but I don't see vital idioms. I see people sometimes use

auto& a = arr[n];

to make sure they take a reference, but we can't define references locally so we can't use that :o).

>> Furthermore, one other unpleasant aftermath of int[$] is that new
>> syntax begets more new syntax. The proverbial ink was not yet dry on
>> the #3615 merge when a new, new syntax was proposed in this forum,
>> this time for statically-allocated statically-sized arrays. Far as I
>> can tell the main argument is "you have to write longer code" without it.
>
> If you're talking about Bearophile's proposed [1, 2]s syntax, he's been
> pushing that for a long time, possibly before [$].

The age of that proposal is irrelevant (except probably for the possibility of it being obviated by language development). The problem is now there is a precedent to back it up.

Let's stop adding every little tidbit to the language. Let's start _using_ the language for awesome things.


Andrei

On Friday, 30 January 2015 at 20:43:10 UTC, Andrei Alexandrescu wrote:
>> I think if you showed someone auto declarations and then showed them
>> something like auto[] arr = [...], their likely reaction would be "well
>> of course that works". Although maybe I'm too familiar with D at this
>> point and that's not the case at all.
>
> Yah, that's nice but needs appropriate formalization. How about auto[auto] to ensure an associative array type, or Xyz!(auto, auto)

staticArray!(int, auto) sarray = [1, 2, 3];

Maybe it is more general and powerful. Also, I believe that Kenji *did* implement auto[auto]. I'm assuming you were just giving examples and not seriously proposing the above, though.

> to ensure template Xyz with exactly two arguments, or even auto!(auto) to match any template instantiated with one argument...?

All interesting ideas.

> It's just getting weird, and not very useful because it's impossible to associate names with those "auto"s. As I mentioned this is sometimes used in C++ but I don't see vital idioms. I see people sometimes use
>
> auto& a = arr[n];
>
> to make sure they take a reference, but we can't define references locally so we can't use that :o).

I am having difficulty thinking of a situation where you want to refer to the auto from something like `int[auto]`. Are you alluding to pattern matching? I do agree that pattern matching is much more powerful, general, and useful then a partial type-deduction feature. I will also point out that partial type deduction for templates, AKA higher-kinded types, has been a great success in D, and it would be great to bring that power into other areas of the language.

This is really all just pleasant diversion thinking about what could be, but I  think we can all at least agree that it will not be a huge blow to D if [$] or partial type deduction gets reverted. This is in spite of the fact that I like the latter, of course.