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
>

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

The one really bad thing about this is that it forces you to declare it as auto.

While having the possibility to write auto is nice, forcing you to do so is quite ugly.

I still to this day hate the Scoped, exactly for the same reason. I just want examples *without* being forced to use auto.

Auto is less clearer about one ecpects an expresion to be.

On 1/30/15 11:00 PM, eles wrote:
> 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.

How is anything about specifying the length of a constant array revolutionary?

> 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.

Special syntax for a niche case instead of using a function... looks one quirk more, not less.


Andrei

On Saturday, 31 January 2015 at 05:21:08 UTC, an wrote:
> On Saturday, 31 January 2015 at 05:07:35 UTC, Kapps wrote:
>>
>> 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'?

Aye, I meant with the .s.

On Saturday, 31 January 2015 at 07:00:05 UTC, eles wrote:
> Everytime I follow the process managemnt and decision in D, it looks to me like IndburIII-esque:

What management? You mean the process that follow the structure:

- analysis
- prioritization
- risk reduction
- design
- implementation
- evaluation
- analysis
- prioritization
- etc

?

What I see is:

- implementation
- analysis
- crisis
- implementation
- analysis
- crisis

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

Can you use it in function parameters?

Will it be made superfluous if you have tuple literals?

How is "$" different from an inferred templated constant?

Does it compete with more generic future concepts?

No planning -> chaos -> high expenses.

On Saturday, 31 January 2015 at 07:19:47 UTC, Andrei Alexandrescu wrote:
> On 1/30/15 11:00 PM, eles wrote:
>> 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.
>
> How is anything about specifying the length of a constant array revolutionary?
>
>> 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.
>
> Special syntax for a niche case instead of using a function... looks one quirk more, not less.
>

Really? What about the niceness of uniformity in declaration?

Imagine that you declare first a dynamic array, then you would like it to be static.

Suddenly you have to quirk.

You defend inconsistency.

On Saturday, 31 January 2015 at 07:57:19 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 31 January 2015 at 07:00:05 UTC, eles wrote:

> Can you use it in function parameters?
>
> Will it be made superfluous if you have tuple literals?

*these* are very different grounds on which to discuss, accept or reject the feature, and they might be valid.

but the grounds that I was criticizing were not this ones. were the grounds of "it ma be done otherwise, just look at this nice bed-of-nails syntax"!

and yes, the process may be improved a bit (more).

On Saturday, 31 January 2015 at 07:19:47 UTC, Andrei Alexandrescu wrote:
> On 1/30/15 11:00 PM, eles wrote:
>> On Friday, 30 January 2015 at 18:08:15 UTC, Gary Willoughby wrote:
>>> On Friday, 30 January 2015 at 14:47:22 UT

> How is anything about specifying the length of a constant array revolutionary?

No. This is not revolutionary, but you are making of it a such fearsome perspective that one's feels like it will gonna blow away the language.

And when I spoke about the revolution that might be wrong, I didn't speak about this.

But precisely of this:

The wrong revolution in D is the GC.

Yes, in that respect, D was revolutionary. And wrong.

A lot of effort, see the recent threads about embedded and realtime, are just wasted energy to alleviate the outcomes of this one bad choice. It seems that the hardest fight the D users have to tackle is with the GC. Just have a look at all the efforts made in this direction (even the allocators and so on), and especially at the *abandoned efforts*.

Anyway, I did not want to develop the topic on this thread because i is a different thing.

>
>> 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.
>
> Special syntax for a niche case instead of using a function... looks one quirk more, not less.

It looks to you that suddenly being forced to go from:

int[3] x = [1, 2, 3];

to

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

or from

auto[$][][$] = [
   [[1,2]],
   [[3,4], [5,6]],
   [[7,8], [9,10], [11,12]],
];

to

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

is a kind of clear, crisp and obvious change?

Frankly, the latter example ae rather a special syntax, not the first one. There, the meaning is almost clear: "I want  static string of a length that I don't want to spend effort in order to count it by hand".

Don't tell me that you did never count characters on the screen with the keyboard, mouse or the finger?

Now, look again at the examples above and *then* ask yourself which is the more unnatural and special syntax.

God, you cannot even get away of that "auto" (which translates into: "I, as a designer, I hide my inability to define a clear syntax here behind this sugar of auto").

So, as I was telling, you manage to be both revolutionary and conservative, just both wrong.

You went the revolutionary road with the GC and so on, sparkling a lot of effort and discussions just to cope with that wrong choice, but you held on onto it, with the determination of IndburIII.

Then, you fight with all your energy against little things that will much sweeten the language, fearful of changes because, after doing one wrong, you fear even the good ones. And you call this being "cautious".

Whatever, anyway.

> Whatever, anyway.

Translation of that being:

"Boring pedestrian issues like simple string logging are bikeshedded for YEARS, yet PhD-level esoteric stuff makes it into phobos with relative ease."

https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md

cautios and determination, isn't? or, revolutionary and conservative, how I did put it...

On Friday, 30 January 2015 at 22:34:25 UTC, Walter Bright wrote:
> Unless a new language feature is a compelling win

You seem to never measure "win" in terms of "user experience", but in "abstract technicality".

Blackberry lost in front of Apple exactly for the same reason.

On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:

> "Boring pedestrian issues like simple string logging are bikeshedded for YEARS, yet PhD-level esoteric stuff makes it into phobos with relative ease."

At least for me, this was a valuable English lesson. I had never quite grasp the meaning of "being fed up" before.