www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should we remove int[$] before 2.067?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.

Furthermore, one other unpleasant aftermath of int[$] is that new syntax 

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.

I am not okay with that - at all.

D is a great language with many awesome features. Too many, in some 
people's opinion. We must get into the habit of using D's ample 
orchestra to create new music, not add a new instrument for every tune.

So I am think we should consider reverting 
https://github.com/D-Programming-Language/dmd/pull/3615 and adding the 
appropriate functions to std.array.

Please advise.


Andrei
Jan 30 2015
next sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 30/01/2015 14:47, Andrei Alexandrescu wrote:

 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.


+1. Also discussed here:
https://issues.dlang.org/show_bug.cgi?id=8008#c8
Jan 30 2015
prev sibling next sibling parent reply Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-01-30 23:47 GMT+09:00 Andrei Alexandrescu via Digitalmars-d <
digitalmars-d puremagic.com>:


 Please advise.



The new feature, I call it "Partial type deduction", is not only for static
array length.
Examples:

void main()
{
    const[] a1 = [1,2,3];   // a mutable array of const ints
    static assert(is(typeof(a1) == const(int)[]));
    a1 ~= 4;                // OK
    static assert(!__traits(compiles, { a1[0] = 10; }));     // cannot
modify const

    immutable[][$] a2 = [[1,2], [3,4]];  // a static array of mutable
dynamic array of immutable ints
    static assert(is(typeof(a2) == immutable(int)[][2]));
    static assert(!__traits(compiles, { a2 ~= [[5,6]]; }));  // cannot
append to static array
    a2[0] = [7,8];          // OK
    assert(a2 == [[7,8], [3,4]]);
    static assert(!__traits(compiles, { a2[0][0] = 100; })); // cannot
modify immutable
}

The type deduction will provide powerful way to type variables.
Yes, ultimately they can be replaced with library function calls, but the
call will be ugly and hard to understand. Consider making a2 by using
library function. Can you show us a concept design for that?

And, staticArray function will not work for the following case:

int function(int)[$] funcs = [
    a => a + 1,
    a => a * 2,
];

The template lambdas have no type until they applied to the type `int
function(int)`. So

auto funcs = staticArray(
    a => a + 1,
    a => a * 2,
);

is clearly impossible.

The core of the feature is a pattern matching for the declared variable
type. I believe it will be useful for declarative style programming.

Kenji Hara
Jan 30 2015
next sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 30/01/2015 16:44, Kenji Hara via Digitalmars-d wrote:

      immutable[][$] a2 = [[1,2], [3,4]];  // a static array of mutable
 dynamic array of immutable ints
      static assert(is(typeof(a2) == immutable(int)[][2]));


...

 The type deduction will provide powerful way to type variables.
 Yes, ultimately they can be replaced with library function calls, but the
 call will be ugly and hard to understand. Consider making a2 by using
 library function. Can you show us a concept design for that?


auto a2 = staticArray!(immutable(int)[])([1,2], [3,4]);

This version of staticArray allows the user to (optionally) specify the 
element type.


 And, staticArray function will not work for the following case:

 int function(int)[$] funcs = [
      a => a + 1,
      a => a * 2,
 ];

 The template lambdas have no type until they applied to the type `int
 function(int)`. So


auto funcs = staticArray!(int function(int))(
       a => a + 1,
       a => a * 2,
     );
Jan 30 2015
next sibling parent reply Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d <
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]],
];
Jan 30 2015
next sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
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 <
 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]],
 ];


alias s = staticArray;
auto arr = staticArray(
       [[1,2].s],
       [[3,4].s, [5,6].s],
       [[7,8].s, [9,10].s, [11,12].s],
  );
Jan 30 2015
parent "eles" <eles eles.com> writes:
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.
Jan 30 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 30 2015
prev sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
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])...
Jan 30 2015
parent reply "Foo" <Foo test.de> writes:
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.
Jan 30 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 30 2015
next sibling parent "Foo" <Foo test.de> writes:
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. ;)
Jan 30 2015
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
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])
Jan 30 2015
next sibling parent reply "an" <anonymous mail.invalid> writes:
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])
Jan 30 2015
parent "Kapps" <opantm2+spam gmail.com> writes:
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.
Jan 30 2015
prev sibling parent "eles" <eles eles.com> writes:
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.
Jan 30 2015
prev sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 30/01/2015 16:44, Kenji Hara via Digitalmars-d wrote:

 The new feature, I call it "Partial type deduction", is not only for static
 array length.


Yes, I think the other improvements are useful, but [$] is not strictly 
necessary. Maybe [$] will turn out to be worth having, but I'm not sure 
that's clear yet.
Jan 30 2015
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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.)


T

-- 
This is not a sentence.
Jan 30 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 30 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 30 2015
prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Friday, 30 January 2015 at 14:47:22 UTC, Andrei Alexandrescu 
wrote:

 So I am think we should consider reverting 
 https://github.com/D-Programming-Language/dmd/pull/3615 and 
 adding the appropriate functions to std.array.

 Please advise.


+1
Woah, please stop adding syntax and focus on stability, libraries 
and interoperability.

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.
Jan 30 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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?=20
fsck, WHY DIDN'T YOU WROTE THAT ON THE FRONT PAGE?! i was thinking about=20
opposite...

p.s. should i submit patches to remove everything that is doable with=20
libraries? my particular target is so-called "floating point numbers".=20
they only adds complexity to codegen and parser, and all floating point=20
functions can be written in pure D. ah, and integer multiplication as a=20
low-hanging fruit.=
Jan 30 2015
prev sibling parent reply "eles" <eles eles.com> writes:
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.
Jan 30 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 30 2015
next sibling parent "eles" <eles eles.com> writes:
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.
Jan 31 2015
prev sibling parent reply "eles" <eles eles.com> writes:
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.
Feb 01 2015
parent reply "eles" <eles eles.com> writes:
 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...
Feb 01 2015
next sibling parent reply "eles" <eles eles.com> writes:
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.
Feb 01 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/1/15 1:54 AM, eles wrote:

 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.


Well I don't know what to say. I agree with some of your points but not 
with most. It's a bummer you are being frustrated, but I know it's 
impossible to please everyone and I'm not sure how we can convert your 
frustration into something productive. -- Andrei
Feb 01 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu 
wrote:

 I know it's impossible to please everyone and I'm not sure how 
 we can convert your frustration into something productive. --


How about designing the language before implementing it? Then one 
can discuss the design, rather than the implementation...

Talk is cheap as you like to point out... So talk more before 
starting on a new cycle, and save the expenses for what is worth 
"paying" for.
Feb 01 2015
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu 
wrote:

 On 2/1/15 1:54 AM, eles wrote:

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





 Well I don't know what to say. I agree with some of your points 
 but not with most. It's a bummer you are being frustrated, but 
 I know it's impossible to please everyone and I'm not sure how 
 we can convert your frustration into something productive. --


One thing that the library-auto solution does not provide is the 
*granularity* of what I ask the compiler to infer.

I want the compiler to infer some things, like the length of the 
static array, but not others, like the type of the elements.

What if I want to go from

float[$] = [1.09, 1.1];

to

int[$] = [1, 1];

but instead I make a mistake and I write:

int[$] = [1, 1.1 /* note that I forgot to drop the decimals here 
*/ ];


The "auto" will give me a floating point array, the program might 
work for a while, than unexpected bugs start arising.

Propensity for bike-shedding behind the covers of intellectual 
refinement puzzles me.
Feb 01 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 01 Feb 2015 15:56:17 +0000, eles wrote:


 Propensity for bike-shedding behind the covers of intellectual
 refinement puzzles me.


this is part of "be smart!" strategy. anyone who is not smart enough=20
doesn't deserve the right to use D. and "being smart" means "manually do=20
the work that compiler can automate".=
Feb 01 2015
next sibling parent "eles" <eles eles.com> writes:
On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote:

 On Sun, 01 Feb 2015 15:56:17 +0000, eles wrote:



 this is part of "be smart!" strategy. anyone who is not smart 
 enough
 doesn't deserve the right to use D. and "being smart" means 
 "manually do
 the work that compiler can automate".


Well, at least, halving the user base has the definite advantage 
that it halves the complains too.
Feb 01 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote:

 On Sun, 01 Feb 2015 15:56:17 +0000, eles wrote:


 Propensity for bike-shedding behind the covers of intellectual
 refinement puzzles me.


 this is part of "be smart!" strategy. anyone who is not smart 
 enough
 doesn't deserve the right to use D. and "being smart" means 
 "manually do
 the work that compiler can automate".


It would help if dynamic-array/slice/fixed-size-array and 
value/reference/ownership types had been well designed from the 
get go.

Inconsistencies in syntax and special casing the typing requires 
the user to "be smart", because the language is "dumb". But 
making the compiler smarter to fix a dumb language is the wrong 
path. The right thing to do is to redesign what is "dumb" (the 
language).
Feb 01 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 02 Feb 2015 00:00:00 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote:

 On Sun, 01 Feb 2015 15:56:17 +0000, eles wrote:


 Propensity for bike-shedding behind the covers of intellectual
 refinement puzzles me.


 this is part of "be smart!" strategy. anyone who is not smart enough
 doesn't deserve the right to use D. and "being smart" means "manually
 do the work that compiler can automate".


=20
 It would help if dynamic-array/slice/fixed-size-array and
 value/reference/ownership types had been well designed from the get go.
=20
 Inconsistencies in syntax and special casing the typing requires the
 user to "be smart", because the language is "dumb". But making the
 compiler smarter to fix a dumb language is the wrong path. The right
 thing to do is to redesign what is "dumb" (the language).


i agree with you, but it's really too late to redesign. :-(
it's not about "code breaking", people just will not join D3 (or=20
something) developement at this stage. especially if Walter and Andrei=20
will not join (and i doubt they will).=
Feb 01 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 2 February 2015 at 05:44:46 UTC, ketmar wrote:

 i agree with you, but it's really too late to redesign. :-(
 it's not about "code breaking", people just will not join D3 (or
 something) developement at this stage.


I don't agree. D does not have a significant set of libraries 
that developers depend on and also not a large installed base.

What prevents Python3 adoption is the massive amount of Python2 
libraries and a perception that you loose more than you gain from 
switching. But people are switching to Python3... and to C++14... 
and to Swift... and to Go... When the installed base moves, 
projects move. Large installed base -> slow moving. No installed 
base -> free to move.


 especially if Walter and Andrei will not join (and i doubt they 
 will).


I think you overestimate the importance of that. It does not 
matter who uses D today. The crux is to appeal to those who do 
not use it, but hacking on it does not fix it for those who have 
left.

Based on what people write in the forums it looks like D now 
appeals more to newbies coming from scripting languages and VM 
languages than those coming from low level C/C++. That might turn 
out to be a very risky market where people switch easily...
Feb 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 02 Feb 2015 09:07:37 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Monday, 2 February 2015 at 05:44:46 UTC, ketmar wrote:

 i agree with you, but it's really too late to redesign. :-( it's not
 about "code breaking", people just will not join D3 (or something)
 developement at this stage.


=20
 I don't agree. D does not have a significant set of libraries that
 developers depend on and also not a large installed base.


but to work on D3 people should be interested in D. and it seems that=20
people who are interested in D and are ready to work on D development=20
already have some codebases. i don't believe that they will welcome yet=20
another codebase conversion. ;-)


 especially if Walter and Andrei will not join (and i doubt they will).


=20
 I think you overestimate the importance of that. It does not matter who
 uses D today. The crux is to appeal to those who do not use it, but
 hacking on it does not fix it for those who have left.


but it's matter who is driving force behind the project. "yet another D=20
fork from people you never heard about" has little chances to be=20
successful. besides, Walter owns DMD codegen. it's not the best codegen=20
in the world, but it's very valuable, 'cause it allows to develop D=20
without installing llvm/gcc crap.
=
Feb 02 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 2 February 2015 at 10:28:37 UTC, ketmar wrote:

 but to work on D3 people should be interested in D. and it 
 seems that people who are interested in D and are ready to
 work on D development
 already have some codebases. i don't believe that they will 
 welcome yet
 another codebase conversion. ;-)


Mmmaybe, but I think more people would be more willing to work on 
the compiler if the goal is to produce a niche language of high 
standards. Basically, a best of breed for niche X.

When features compete in a way that makes it impossible to be the 
best in any niche, then that basically kills motivation (at least 
mine).  Complex languages that grow are usually best of breed in 
their niche for solving "hard problems".

D is getting complicated, but not to solve hard problems. That is 
not a good tradeoff.

There are plenty of simple languages for solving easy problems.


 but it's matter who is driving force behind the project. "yet 
 another D
 fork from people you never heard about" has little chances to be
 successful.


Stability, quality and performance. Kill the less important stuff 
and move for performance. Performance generally trumps other 
parameters if you are actively getting benchmarks published IMHO.

To get performance you need to focus on one platform first.

D is expanding everywhere, even in the standard library... Not 
good. D cannot build "high quality anything" without staying 
focused. High quality means hardware optimized and best of breed.

Just take a look at the numerical library in D, basically 
empty... If you don't have the resources to make the numerical 
library look complete then leave it all to a third party.
Feb 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 02 Feb 2015 14:11:20 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Monday, 2 February 2015 at 10:28:37 UTC, ketmar wrote:

 but to work on D3 people should be interested in D. and it seems that
 people who are interested in D and are ready to work on D development
 already have some codebases. i don't believe that they will welcome yet
 another codebase conversion. ;-)


=20
 Mmmaybe, but I think more people would be more willing to work on the
 compiler if the goal is to produce a niche language of high standards.
 Basically, a best of breed for niche X.


so it should have defined niche then. sadly, D hasn't, as it tries to be=20
"good system language", "good high-level language" and even "good=20
scripting language" to some extent.

i, for example, see D as something intermediate between "system" and=20
"high-level". for me it's really "better C with classes (and structs)".=20
and lambdas, which i'm using in gcc too. and i don't really need that=20
" safe" and "pure" things -- hey, if compiler is able to check that, it's=20
able to infer that, so do it and just get out of my way! ah, and "nothrow"=20
too. let me force that if i want, but otherwise don't burden my sources.

sure, to fully exploit that (and other things) it's better to drop that=20
oldish "object files" concept and use something like delphi's .dcu.


 When features compete in a way that makes it impossible to be the best
 in any niche, then that basically kills motivation (at least mine).


me too: i still can't understand what kind of language D tries to be.


 Stability, quality and performance. Kill the less important stuff and
 move for performance. Performance generally trumps other parameters if
 you are actively getting benchmarks published IMHO.


performance can be left to gcc branch: let gcc people write optimisers=20
for us! ;-) ah, and architecture support too.


 To get performance you need to focus on one platform first.


not necessary. just stop using homegrown codegen for anything except=20
compiler prototypes. develop new features and fixes with prototype=20
comiler, which is able to produce working code, but doesn't even try to=20
do "native" optimisations, and then use gcc as backend for releases.
=
Feb 02 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 2 February 2015 at 15:24:15 UTC, ketmar wrote:

 and lambdas, which i'm using in gcc too. and i don't really 
 need that
 " safe" and "pure" things -- hey, if compiler is able to check 
 that, it's
 able to infer that, so do it and just get out of my way! ah, 
 and "nothrow"
 too. let me force that if i want, but otherwise don't burden my 
 sources.


Yeah, I'm not really into all those constraints. I want power, 
not limitations and tedium. ;-)


 sure, to fully exploit that (and other things) it's better to 
 drop that
 oldish "object files" concept and use something like delphi's 
 .dcu.


I am not familiar with that format, but using a high level 
intermediate representation format is the way to go for whole 
program optimization IMO...


 not necessary. just stop using homegrown codegen for anything 
 except
 compiler prototypes. develop new features and fixes with 
 prototype
 comiler, which is able to produce working code, but doesn't 
 even try to
 do "native" optimisations, and then use gcc as backend for 
 releases.


Well, one should look to other architectures, but getting high 
performance levels takes focus. I am not sure if one can get 
beyond C++ by spreading out on all platforms. Intel intrinsics 
are in the thousands, and the libraries (and high level 
optimizer) probably should use those where they are a good fit...
Feb 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 02 Feb 2015 19:13:13 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 sure, to fully exploit that (and other things) it's better to drop that
 oldish "object files" concept and use something like delphi's .dcu.


=20
 I am not familiar with that format, but using a high level intermediate
 representation format is the way to go for whole program optimization
 IMO...


it's practically a ".di" file, but in compact binary representation. or=20
even a full ".d" file for that matter. it's already parsed, checked,=20
analyzed, maybe even some code emited -- but no AST/type information is=20
lost. well, .dcus doesn't keep AST, but D ".dcm" can. ;-)

they also can be used by tools too.


 Well, one should look to other architectures, but getting high
 performance levels takes focus. I am not sure if one can get beyond C++
 by spreading out on all platforms. Intel intrinsics are in the
 thousands, and the libraries (and high level optimizer) probably should
 use those where they are a good fit...


i think that this is the area that can be left to "platform-specific"=20
part of the specs. maybe even omited completely, as it's highly backend/
arch dependent. if someone want to squeeze every cycle possible, he knows=20
that his code will be unportable mess. ;-)=
Feb 02 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 2 February 2015 at 20:51:02 UTC, ketmar wrote:

 i think that this is the area that can be left to 
 "platform-specific"
 part of the specs. maybe even omited completely, as it's highly 
 backend/
 arch dependent. if someone want to squeeze every cycle 
 possible, he knows
 that his code will be unportable mess. ;-)


Not a portable mess per se, you can have platform support 
described in the docs with performance notes.

Most OSes have been geared towards C and Posix at some point and 
x86 is currently king, but hardware/coprocessors/memory 
architecture can be very different. Just wait till FPGAs become 
mainstream :-P. Don't mistake "unix-style-hardware" for portable 
code ;^)

http://www.extremetech.com/extreme/184828-intel-unveils-new-xeon-chip-with-integrated-fpga-touts-20x-performance-boost
Feb 02 2015
prev sibling parent reply "eles" <eles eles.com> writes:
On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu 
wrote:

 On 2/1/15 1:54 AM, eles wrote:

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






 I know it's impossible to please everyone and I'm not sure how


But that everyone is many. Have a look, please, at the comments 
made on github for exactly that pull request. Almost all involved 
seemed to be happy with it (Hara, Andrej, Martin -- sorry for 
citing names, I don't usually do that), even Walter and you.

Some even hinted that they awaited this for long.

BTW, the original request was filled in 2006. That makes it for 9 
years. For a simple feature.

9 years...
Feb 01 2015
next sibling parent "eles" <eles eles.com> writes:
On Sunday, 1 February 2015 at 16:09:24 UTC, eles wrote:

 On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu 
 wrote:

 On 2/1/15 1:54 AM, eles wrote:

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






 I know it's impossible to please everyone and I'm not sure how


 But that everyone is many. Have a look, please, at the comments 
 made on github for exactly that pull request. Almost all 
 involved seemed to be happy with it (Hara, Andrej, Martin --


+ bearophile
Feb 01 2015
prev sibling parent reply "eles" <eles eles.com> writes:
On Sunday, 1 February 2015 at 16:09:24 UTC, eles wrote:

 On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu 
 wrote:

 On 2/1/15 1:54 AM, eles wrote:

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







 9 years...


And, for what it matters, 9 years of *indecision*.

It wasn't a good or bad decision. It was "it might be a better 
way". Well, after 9 years, there is still no better way in sight 
and, still, the brink of another non-decision is glooming that 
fast.
Feb 01 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/1/15 8:24 AM, eles wrote:

 On Sunday, 1 February 2015 at 16:09:24 UTC, eles wrote:

 On Sunday, 1 February 2015 at 15:31:29 UTC, Andrei Alexandrescu wrote:

 On 2/1/15 1:54 AM, eles wrote:

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







 9 years...


 And, for what it matters, 9 years of *indecision*.

 It wasn't a good or bad decision. It was "it might be a better way".
 Well, after 9 years, there is still no better way in sight and, still,
 the brink of another non-decision is glooming that fast.


I agree indecision is bad. -- Andrei
Feb 01 2015
parent David Gileadi <gileadis NSPMgmail.com> writes:
On 2/1/15 9:26 AM, Andrei Alexandrescu wrote:

 I agree indecision is bad. -- Andrei


Whereas I'm still on the fence...
Feb 02 2015
prev sibling next sibling parent reply "uri" <uri.grill gmail.com> writes:
On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:

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


+1

At least decisions are finally being made on several fronts 
recently though.

W.r.t this feature, I was personally looking forward to it ... 
guess I'll stick with the Octave/R/Python "troika" for rapid 
protoyping numerical analysis code.
Feb 01 2015
next sibling parent "eles" <eles eles.com> writes:
On Sunday, 1 February 2015 at 10:00:38 UTC, uri wrote:

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





 W.r.t this feature, I was personally looking forward to it ... 
 guess I'll stick with the Octave/R/Python "troika" for rapid 
 protoyping numerical analysis code.


Unfortunately for D, many of the wannabe users reach similar 
conclusions in the end...



 Feb 01 2015



prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/1/15 2:00 AM, uri wrote:

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

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


 +1

 At least decisions are finally being made on several fronts recently
 though.

 W.r.t this feature, I was personally looking forward to it ... guess
 I'll stick with the Octave/R/Python "troika" for rapid protoyping
 numerical analysis code.


Which feature are you referring to? -- Andrei



 Feb 01 2015



  parent reply "uri" <uri.grill gmail.com>  writes:


On Sunday, 1 February 2015 at 15:36:04 UTC, Andrei Alexandrescu 
wrote:

 On 2/1/15 2:00 AM, uri wrote:

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

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


 +1

 At least decisions are finally being made on several fronts 
 recently
 though.

 W.r.t this feature, I was personally looking forward to it ... 
 guess
 I'll stick with the Octave/R/Python "troika" for rapid 
 protoyping
 numerical analysis code.


 Which feature are you referring to? -- Andrei


int[$] a=[1,2,3];

The syntax sugar helps when prototyping ideas, which is why R and 
Octave (MATLAB) are so useful. I have reservations about this:

auto a=[1,2,3].s

Because the type is hidden from the programmer... For my use case 
(prototyping code) it's a don't care but in production code it 
might be a problem, as others have pointed out already. I 
actually use this trick already in my own code for malloc'd 
arrays to avoid the GC and add sugar to toStringz.

All in all it is great to see some decisions been made. I think 
it will help shut down bike shedding and get D moving forward at 
a faster rate.

Cheers uri



 Feb 01 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/1/15 1:03 PM, uri wrote:

 int[$] a=[1,2,3];

 The syntax sugar helps when prototyping ideas, which is why R and Octave
 (MATLAB) are so useful.


Do R, Octave, or Matlab have the ability to define arrays on the stack? 
-- Andrei



 Feb 01 2015



  parent  "stewarth" <growlercab gmail.com>  writes:


On Sunday, 1 February 2015 at 23:19:53 UTC, Andrei Alexandrescu 
wrote:

 On 2/1/15 1:03 PM, uri wrote:

 int[$] a=[1,2,3];

 The syntax sugar helps when prototyping ideas, which is why R 
 and Octave
 (MATLAB) are so useful.


 Do R, Octave, or Matlab have the ability to define arrays on 
 the stack? -- Andrei


No they don't, at least not to my knowledge and we use Matlab 
every day at my workplace.

I think what Uri is referring to is the very low resistance once 
sees in the syntax of R, Matlab, Python when going from an idea 
or algorithm on paper to code.

I've always found dynamic arrays in D are perfectly fine for 
rapid prototyping code, however, my situation may be different 
from that Uri.


Cheers,
stew



 Feb 01 2015



prev sibling  parent reply "Tobias Pankrath" <tobias pankrath.net>  writes:


On Sunday, 1 February 2015 at 10:00:38 UTC, uri wrote:

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





 W.r.t this feature, I was personally looking forward to it ... 
 guess I'll stick with the Octave/R/Python "troika" for rapid 
 protoyping numerical analysis code.


Because static arrays are not convenient enough to use, I'll have 
to use another language that does not even provide static arrays. 
Makes sense.



 Feb 01 2015



 next sibling parent  "eles" <eles eles.com>  writes:


On Sunday, 1 February 2015 at 15:41:38 UTC, Tobias Pankrath wrote:

 On Sunday, 1 February 2015 at 10:00:38 UTC, uri wrote:

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







 Because static arrays are not convenient enough to use, I'll 
 have to use another language that does not even provide static 
 arrays. Makes sense.


But they provide other things. Despite what some seem to assume, 
regular people are not martyrs looking for the D sword to let 
themselves fall onto.

There are many others appealing swords out there.



 Feb 01 2015



prev sibling  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Sunday, 1 February 2015 at 15:41:38 UTC, Tobias Pankrath wrote:

 Because static arrays are not convenient enough to use, I'll 
 have to use another language that does not even provide static 
 arrays. Makes sense.


Kind of OT, but can we drop this static/dynamic/associative array 
thing ? array/lice/maps seems more appropriate, unless we want to 
confuse everybody.



 Feb 01 2015



  parent  Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 2/1/15, deadalnix via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Sunday, 1 February 2015 at 15:41:38 UTC, Tobias Pankrath wrote:

 Because static arrays are not convenient enough to use, I'll
 have to use another language that does not even provide static
 arrays. Makes sense.


 Kind of OT, but can we drop this static/dynamic/associative array
 thing ? array/lice/maps seems more appropriate, unless we want to
 confuse everybody.


Let's call static arrays fixed-size arrays IMO.



 Feb 01 2015



prev sibling  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 1 February 2015 at 09:46, eles via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

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


What I read in that link is:

I would have tried again... I was out of patience and energy... I
didn't want to hack on DMD...  (I made up the last quote)

Nothing happens if you lack any desire to work.



 Feb 01 2015



prev sibling  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


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.



 Jan 30 2015



  parent reply "eles" <eles eles.com>  writes:


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



 Feb 01 2015



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Sunday, 1 February 2015 at 09:20:11 UTC, eles wrote:

 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"!


Yeah, I agree that the library solution for what should be 
builtin makes no sense.

In language design it is often a good idea to prototype potential 
language features as a library solution first, but not in the 
standard library...



 Feb 01 2015



  parent  "eles" <eles eles.com>  writes:


On Sunday, 1 February 2015 at 15:46:44 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 1 February 2015 at 09:20:11 UTC, eles wrote:



 Yeah, I agree that the library solution for what should be 
 builtin makes no sense.


Yet, there is such a bias for over-appreciating the library 
features... an overappreciation that I fail to understand or see 
benefits of it beyond a certain point.

I guess it has to do with orthogonality or with the 
"easy-implementation" of the language.

All this wile forgetting that as long as the elephant in the room 
is the GC, all other things combined matter less.



 Feb 01 2015



prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com>  writes:


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.



 Jan 30 2015



  parent  "ixid" <nuaccount gmail.com>  writes:


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?



 Jan 30 2015



prev sibling next sibling parent reply "Meta" <jared771 gmail.com>  writes:


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 

 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 [$].



 Jan 30 2015



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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

 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



 Jan 30 2015



  parent  "Meta" <jared771 gmail.com>  writes:


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.



 Jan 30 2015



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Jan 30 2015



  parent  "eles" <eles eles.com>  writes:


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.



 Feb 01 2015



prev sibling next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


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.



 Jan 30 2015



  parent  "Dicebot" <public dicebot.lv>  writes:


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



 Jan 30 2015



prev sibling next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


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



 Jan 30 2015



prev sibling  parent  "Foo" <Foo test.de>  writes:


Maybe someone should remove this from the Changelog?
http://dlang.org/changelog.html#partial-type



 Feb 07 2015