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

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