On 1/30/2015 10:21 AM, Andrei Alexandrescu wrote:
> On 1/30/15 9:57 AM, H. S. Teoh via Digitalmars-d wrote:
>> 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.


Sometimes taking action stimulates thinking about it that never would happen otherwise. I don't see how adding more process would have the same effect.

Unless a new language feature is a compelling win, we should err on the side of being conservative.

With the array.s library function idea, it seems that the utility of this new syntax is greatly reduced.

I say no.

On Fri, 30 Jan 2015 18:08:13 +0000, Gary Willoughby wrote:

> We don't want the situation of C++ where people only use 80% of it's features and that 80% is different for everyone. I've recently been writing some Go code and it's become clear to me just how big of a language D really is.

that is the plan for D? screw the expressiveness, do it One Right Way? fsck, WHY DIDN'T YOU WROTE THAT ON THE FRONT PAGE?! i was thinking about opposite...

p.s. should i submit patches to remove everything that is doable with libraries? my particular target is so-called "floating point numbers". they only adds complexity to codegen and parser, and all floating point functions can be written in pure D. ah, and integer multiplication as a low-hanging fruit.

On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu wrote:
>
> 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

With a library method of [1, 2, 3].s, or syntax of [1, 2, 3]s, would this proposed $ syntax really provide any benefit? Since you could already use 'auto a = [1, 2, 3]' for size inference, I don't really see a strong benefit over 'int[$] a = [1, 2, 3]' with the exception that you could specify the type in the latter.

More so, I think having .s is a much better alternative if there's no substantial advantage to $, because it can also be used as an expression for purposes such as making function calls with a static array.

Example:
auto foo = Variant([1, 2, 3].s)
rather than
auto foo = Variant(cast(int[$])[1, 2, 3])

On Saturday, 31 January 2015 at 05:07:35 UTC, Kapps wrote:
> On Friday, 30 January 2015 at 19:07:53 UTC, Andrei Alexandrescu wrote:
>>
>> 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
>
> With a library method of [1, 2, 3].s, or syntax of [1, 2, 3]s, would this proposed $ syntax really provide any benefit? Since you could already use 'auto a = [1, 2, 3]' for size inference,

Did you mean 'auto a = [1, 2, 3].s'?

auto    a = [1, 2, 3]; // int[]
auto[$] b = [1, 2, 3]; // int[3]

> I don't really see a strong benefit over 'int[$] a = [1, 2, 3]' with the exception that you could specify the type in the latter.
>
> More so, I think having .s is a much better alternative if there's no substantial advantage to $, because it can also be used as an expression for purposes such as making function calls with a static array.
>
> Example:
> auto foo = Variant([1, 2, 3].s)
> rather than
> auto foo = Variant(cast(int[$])[1, 2, 3])

If it is only a way to infer static array types I am inclined to agree that benefit is not big enough. If some more powerful and generic inference is built on top of it that would be a different story - but I haven't followed that specific discussion and don't know if there is anything extra planned.

P.S. does it have a DIP? Is it http://wiki.dlang.org/DIP34 ?

Kill it with fire. It add language complexity and is not pulling its weight.

On Friday, 30 January 2015 at 18:08:15 UTC, Gary Willoughby wrote:
> On Friday, 30 January 2015 at 14:47:22 UT

> We don't want the situation of C++ where people only use 80% of it's features and that 80% is different for everyone. I've recently been writing some Go code and it's become clear to me just how big of a language D really is.

You miss one point here. C++  is not despised for being complete, but for being ugly. Is not features in it that are too many, but the quirks.

Add more quirks to D instead of a lean syntax. This way you will end with C++.

You guys should watch again The last thing D needs. Library syntax shows 'it can be done' but *as a quirk*

Frankly, you can already do *everything* just by typing 'asm', isn't? You really want to stay there?

Everytime I follow the process managemnt and decision in D, it looks to me like IndburIII-esque:

'To him, a stilted geometric love of arrangement was "system," an indefatigable and feverish interest in the pettiest facets of day-to-day bureaucracy was "industry," indecision when right was "caution," and blind stubbornness when wrong, "determination."'

It is one thing to thrieve for caution and determination. But another thing to get those in the right way.

Right now, guys, you are going on the wrong road. Being conservative when wrong and revolutionary when wrong too.

Certainly, you end up by being both conservative and revolutionary. But, neither when it is needed.

I really support the syntax. Because makes one quirk less.

On Friday, 30 January 2015 at 17:06:31 UTC, Nick Treleaven wrote:
> On 30/01/2015 17:01, Kenji Hara via Digitalmars-d wrote:
>> 2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d <

> alias s = staticArray;
> auto arr = staticArray(
>       [[1,2].s],
>       [[3,4].s, [5,6].s],
>       [[7,8].s, [9,10].s, [11,12].s],
>  );

That's coding for masochists, sorry.