Re: Should we remove int[$] before 2.067?
Maybe someone should remove this from the Changelog? http://dlang.org/changelog.html#partial-type
Re: Should we remove int[$] before 2.067?
On Mon, 02 Feb 2015 19:13:13 +, Ola Fosheim Grøstad 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. 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 even a full .d file for that matter. it's already parsed, checked, analyzed, maybe even some code emited -- but no AST/type information is 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 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. ;-) signature.asc Description: PGP signature
Re: Should we remove int[$] before 2.067?
On 2/1/15 9:26 AM, Andrei Alexandrescu wrote: I agree indecision is bad. -- Andrei Whereas I'm still on the fence...
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
On Mon, 02 Feb 2015 09:07:37 +, Ola Fosheim Grøstad 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. 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 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. ;-) 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. 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. besides, Walter owns DMD codegen. it's not the best codegen in the world, but it's very valuable, 'cause it allows to develop D without installing llvm/gcc crap. signature.asc Description: PGP signature
Re: Should we remove int[$] before 2.067?
On Mon, 02 Feb 2015 14:11:20 +, Ola Fosheim Grøstad 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. ;-) 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 good system language, good high-level language and even good scripting language to some extent. i, for example, see D as something intermediate between system and high-level. for me it's really better C with classes (and structs). 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. 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. 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 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 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. signature.asc Description: PGP signature
Re: Should we remove int[$] before 2.067?
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...
Re: Should we remove int[$] before 2.067?
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...
Re: Should we remove int[$] before 2.067?
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...
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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...
Re: Should we remove int[$] before 2.067?
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).
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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...
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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...
Re: Should we remove int[$] before 2.067?
On Sun, 01 Feb 2015 15:56:17 +, 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. signature.asc Description: PGP signature
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote: On Sun, 01 Feb 2015 15:56:17 +, 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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote: On Sun, 01 Feb 2015 15:56:17 +, 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).
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
On Mon, 02 Feb 2015 00:00:00 +, Ola Fosheim Grøstad wrote: On Sunday, 1 February 2015 at 16:09:02 UTC, ketmar wrote: On Sun, 01 Feb 2015 15:56:17 +, 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). 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. especially if Walter and Andrei will not join (and i doubt they will). signature.asc Description: PGP signature
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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, );
Re: Should we remove int[$] before 2.067?
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], );
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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]], ];
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
On Fri, 30 Jan 2015 18:08:13 +, Gary Willoughby wrote: We don't want the situation of C++ where people only use 80% of it's features and that 80% is different for everyone. I've recently been writing some Go code and it's become clear to me just how big of a language D really is. that is the plan for D? screw the expressiveness, do it One Right Way? fsck, WHY DIDN'T YOU WROTE THAT ON THE FRONT PAGE?! i was thinking about opposite... p.s. should i submit patches to remove everything that is doable with libraries? my particular target is so-called floating point numbers. they only adds complexity to codegen and parser, and all floating point functions can be written in pure D. ah, and integer multiplication as a low-hanging fruit. signature.asc Description: PGP signature
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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])...
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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 [$].
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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 autos. 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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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?
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
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
Re: Should we remove int[$] before 2.067?
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. ;)
Re: Should we remove int[$] before 2.067?
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 autos. 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
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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'? autoa = [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])
Re: Should we remove int[$] before 2.067?
P.S. does it have a DIP? Is it http://wiki.dlang.org/DIP34 ?
Re: Should we remove int[$] before 2.067?
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])
Re: Should we remove int[$] before 2.067?
Kill it with fire. It add language complexity and is not pulling its weight.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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.
Re: Should we remove int[$] before 2.067?
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
