www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Discussion Thread: DIP 1039--Static Arrays with Inferred

reply Mike Parker <aldacron gmail.com> writes:
This is the discussion thread for the first round of Community 
Review of DIP 1039, "Static Arrays with Inferred Length":

https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md

The review period will end at 11:59 PM ET on January 20, or when 
I make a post declaring it complete. Discussion in this thread 
may continue beyond that point.

Here in the discussion thread, you are free to discuss anything 
and everything related to the DIP. Express your support or 
opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the 
proposal itself, then please post it in the feedback thread. The 
feedback thread will be the source for the review summary that I 
will write at the end of this review round. I will post a link to 
that thread immediately following this post. Just be sure to read 
and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and 
Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are 
completely off-topic.
Jan 06
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote:

 However, if you have any specific feedback on how to improve 
 the proposal itself, then please post it in the feedback 
 thread. The feedback thread will be the source for the review 
 summary that I will write at the end of this review round. I 
 will post a link to that thread immediately following this post.
The Feedback Thread is here: https://forum.dlang.org/post/qglydztoqxhhcurvbxhs forum.dlang.org
Jan 06
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote:
 On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote:

 However, if you have any specific feedback on how to improve 
 the proposal itself, then please post it in the feedback 
 thread. The feedback thread will be the source for the review 
 summary that I will write at the end of this review round. I 
 will post a link to that thread immediately following this 
 post.
The Feedback Thread is here: https://forum.dlang.org/post/qglydztoqxhhcurvbxhs forum.dlang.org
Before posting a review, I have a question: What was the problem exactly with Kenji H.'s work ? How is the same problem addressed ? I presume this is by forbidding the new syntax in templates decl ? (nothing is explained here https://github.com/dlang/dmd/pull/4373)
Jan 06
parent Basile B. <b2.temp gmx.com> writes:
On Wednesday, 6 January 2021 at 09:55:34 UTC, Basile B. wrote:
 On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote:
 On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker 
 wrote:

 [...]
The Feedback Thread is here: https://forum.dlang.org/post/qglydztoqxhhcurvbxhs forum.dlang.org
Before posting a review, I have a question: What was the problem exactly with Kenji H.'s work ? How is the same problem addressed ? I presume this is by forbidding the new syntax in templates decl ? (nothing is explained here https://github.com/dlang/dmd/pull/4373)
well never mind, I've mentioned in the review that nothing is explaiend about the old attempt.
Jan 06
prev sibling parent reply angel <andrey.gelman gmail.com> writes:
On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote:

 The Feedback Thread is here:
 https://forum.dlang.org/post/qglydztoqxhhcurvbxhs forum.dlang.org
Why not "int[auto] arr = [1, 2, 3]" ? IMHO auto keyword is less ambiguous than $.
Jan 06
parent reply Mathias LANG <geod24 gmail.com> writes:
On Wednesday, 6 January 2021 at 13:48:52 UTC, angel wrote:
 On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote:

 The Feedback Thread is here:
 https://forum.dlang.org/post/qglydztoqxhhcurvbxhs forum.dlang.org
Why not "int[auto] arr = [1, 2, 3]" ? IMHO auto keyword is less ambiguous than $.
Someone else could misunderstand `auto` to mean partial type deduction on associative array, e.g. `int[auto] arr = ["Hello": ubyte(1), "World": ubyte(2)];`. Personally, I think `$` is very natural here, but I also didn't consider `auto` before.
Jan 06
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 6 January 2021 at 14:03:14 UTC, Mathias LANG wrote:
 On Wednesday, 6 January 2021 at 13:48:52 UTC, angel wrote:
 On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker 
 wrote:

 The Feedback Thread is here:
 https://forum.dlang.org/post/qglydztoqxhhcurvbxhs forum.dlang.org
Why not "int[auto] arr = [1, 2, 3]" ? IMHO auto keyword is less ambiguous than $.
Someone else could misunderstand `auto` to mean partial type deduction on associative array, e.g. `int[auto] arr = ["Hello": ubyte(1), "World": ubyte(2)];`. Personally, I think `$` is very natural here, but I also didn't consider `auto` before.
$ is very much appropriate imho, as it implies the length of the array. auto suggests a type (or storage class) and has only barely a link with arrays.
Jan 06
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
I am in favour of more controlled type inference in general, but 
perhaps this one is a bit specific. What if you defined "_" to 
mean "deduce whatever should be in this spot", not only for 
static arrays, but for all types?


Then you could do:

int[_] = …

or

_[_] …


etc
Jan 06
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim Grøstad 
wrote:
 I am in favour of more controlled type inference in general, 
 but perhaps this one is a bit specific. What if you defined "_" 
 to mean "deduce whatever should be in this spot", not only for 
 static arrays, but for all types?


 Then you could do:

 int[_] = …

 or

 _[_] …


 etc
'$' is not an ident char, that's why that works
Jan 06
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 6 January 2021 at 10:58:23 UTC, Basile B. wrote:
 '$' is not an ident char, that's why that works
Yeah, but "$" means length in D. I think it would be valuable to have more generic constraints than the DIP suggests so that it can be useful in multiple contexts. Would appropriating "_" break a lot of code?
Jan 06
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim Grøstad 
wrote:
 int[_] = …

 or

 _[_] …
To expand on this with more examples, you might want to constrain "auto" in various ways with pattern matching: // ensure static array of something with length 4 _[4] v = f(); // ensure that I get a MyContainer with some unspecified type elements MyContainer<_> c = g(); // define a function that swaps the content of an array of length 2 void swap(ref _[2] a){ … } // it would also be shorter than auto, but not sure if that is a good thing _ x = 3 // same as "auto x = 3"
Jan 06
parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 6 January 2021 at 11:11:41 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim 
 Grøstad wrote:
 int[_] = …

 or

 _[_] …
To expand on this with more examples, you might want to constrain "auto" in various ways with pattern matching: // ensure static array of something with length 4 _[4] v = f(); // ensure that I get a MyContainer with some unspecified type elements MyContainer<_> c = g(); // define a function that swaps the content of an array of length 2 void swap(ref _[2] a){ … } // it would also be shorter than auto, but not sure if that is a good thing _ x = 3 // same as "auto x = 3"
I thought about auto when reading the DIP too, but auto is more used like a Type (although being a storage class ;) ). It's never used to infer a value, i.e an expression. While I understand what you mean this is unrelated. Dollar is very well suited. Maybe you could create the underscore-lang to showcase the idea ;)
Jan 06
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 6 January 2021 at 11:18:22 UTC, Basile B. wrote:
 I thought about auto when reading the DIP too, but auto is more 
 used like a Type (although being a storage class ;) ). It's 
 never used to infer a value, i.e an expression. While I 
 understand what you mean this is unrelated. Dollar is very well 
 suited.
Hmm... My take is that this proposal is auto with a constraint, except it will also do implicit conversion.
Jan 06
parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 6 January 2021 at 11:29:42 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 6 January 2021 at 11:18:22 UTC, Basile B. wrote:
 I thought about auto when reading the DIP too, but auto is 
 more used like a Type (although being a storage class ;) ). 
 It's never used to infer a value, i.e an expression. While I 
 understand what you mean this is unrelated. Dollar is very 
 well suited.
Hmm... My take is that this proposal is auto with a constraint, except it will also do implicit conversion.
yeah the split of DIP feedbacks and DIP discussions was clearly not a bad thing ^^
Jan 06
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 6 January 2021 at 11:39:08 UTC, Basile B. wrote:
 Hmm...

 My take is that this proposal is auto with a constraint, 
 except it will also do implicit conversion.
yeah the split of DIP feedbacks and DIP discussions was clearly not a bad thing ^^
Do you disagree?
Jan 06
parent reply Basile B. <b2.temp gmx.com> writes:
On Wednesday, 6 January 2021 at 11:55:12 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 6 January 2021 at 11:39:08 UTC, Basile B. wrote:
 Hmm...

 My take is that this proposal is auto with a constraint, 
 except it will also do implicit conversion.
yeah the split of DIP feedbacks and DIP discussions was clearly not a bad thing ^^
Do you disagree?
No. I agree. Do you imagine if this conversation was in the offical DIP review. E.g those two a**holes who troll the review process /s
Jan 06
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 6 January 2021 at 12:02:05 UTC, Basile B. wrote:
 No. I agree. Do you imagine if this conversation was in the 
 offical DIP review.
 E.g those two a**holes who troll the review process /s
LOL, people have their own frame of reference so the shorter the DIP the more interpretations you get. :-D
Jan 06
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote:
 Here in the discussion thread, you are free to discuss anything 
 and everything related to the DIP. Express your support or 
 opposition, debate alternatives, argue the merits, etc.
I think the DIP is useful and deals properly with degenerated cases.
Jan 06
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2021-01-06 10:21, Mike Parker wrote:
 This is the discussion thread for the first round of Community Review of 
 DIP 1039, "Static Arrays with Inferred Length":
 
 https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7
969/DIPs/DIP1039.md 
There's `staticArray` to solve this issue [1]. [1] https://dlang.org/phobos/std_array.html#.staticArray -- /Jacob Carlborg
Jan 06
next sibling parent reply Luhrel <lucien.perregaux gmail.com> writes:
On Wednesday, 6 January 2021 at 17:59:57 UTC, Jacob Carlborg 
wrote:
 On 2021-01-06 10:21, Mike Parker wrote:
 This is the discussion thread for the first round of Community 
 Review of DIP 1039, "Static Arrays with Inferred Length":
 
 https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md
There's `staticArray` to solve this issue [1]. [1] https://dlang.org/phobos/std_array.html#.staticArray
It works only for the `int` type and above (and other types as structs). example with short: --- extern(C) void main() { import std.array; auto a = [0, 1].staticArray!short; // error } --- To fix that, I need to cast every element: --- extern(C) void main() { import std.array; auto a = [cast(short) 1, cast(short) 2].staticArray!short; // ok } ---
Jan 06
next sibling parent reply Nick Treleaven <nick geany.org> writes:
On Wednesday, 6 January 2021 at 18:14:42 UTC, Luhrel wrote:
 It works only for the `int` type and above (and other types as 
 structs).

 example with short:
 ---
 extern(C) void main()
 {
     import std.array;
     auto a = [0, 1].staticArray!short;  // error
 }
Can be fixed (probably with another name): //import std.array; import std.stdio; void main(){ auto a = [1,2,3].staticArray!float; pragma(msg, typeof(a)); // float[3] a.writeln(); } template staticArray(T) { T[n] staticArray(ulong n) (auto ref T[n] a) {return a;} }
Jan 06
parent reply Nick Treleaven <nick geany.org> writes:
On Wednesday, 6 January 2021 at 18:29:05 UTC, Nick Treleaven 
wrote:
 Can be fixed (probably with another name):

 //import std.array;
Actually template overloading seems to work fine: template staticArray(T) { T[n] staticArray(ulong n) (auto ref T[n] a) {return a;} } T[n] staticArray(T, ulong n) (auto ref T[n] a) {return a;} void main(){ auto a = [1,2,3].staticArray!float; pragma(msg, typeof(a)); // float[3] a.writeln(); [1,2,3].staticArray.writeln(); }
Jan 06
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 6 January 2021 at 18:34:31 UTC, Nick Treleaven 
wrote:
 On Wednesday, 6 January 2021 at 18:29:05 UTC, Nick Treleaven 
 wrote:
 Can be fixed (probably with another name):

 //import std.array;
Actually template overloading seems to work fine: template staticArray(T) { T[n] staticArray(ulong n) (auto ref T[n] a) {return a;} } T[n] staticArray(T, ulong n) (auto ref T[n] a) {return a;} void main(){ auto a = [1,2,3].staticArray!float; pragma(msg, typeof(a)); // float[3] a.writeln(); [1,2,3].staticArray.writeln(); }
What about something like below to handle any user-defined type. import std.stdio: writeln; template staticArray(T) { T[n] staticArray(ulong n) (auto ref T[n] a) {return a;} T[n] staticArray(U, ulong n) (auto ref U[n] a) if (!is(T == U)) { T[n] output; for(size_t i = 0; i < n; i++) { output[i] = cast(T) a[i]; } return output; } } T[n] staticArray(T, ulong n) (auto ref T[n] a) {return a;} struct Foo { float x; T opCast(T)() { return cast(T) x; } } void main(){ auto a = [1,2,3].staticArray!float; pragma(msg, typeof(a)); // float[3] a.writeln(); [1,2,3].staticArray.writeln(); auto b = [1,2,3].staticArray!Foo; b.writeln(); }
Jan 06
parent Luhrel <lucien.perregaux gmail.com> writes:
On Wednesday, 6 January 2021 at 19:04:14 UTC, jmh530 wrote:
 On Wednesday, 6 January 2021 at 18:34:31 UTC, Nick Treleaven 
 wrote:
 [...]
What about something like below to handle any user-defined type. import std.stdio: writeln; template staticArray(T) { T[n] staticArray(ulong n) (auto ref T[n] a) {return a;} T[n] staticArray(U, ulong n) (auto ref U[n] a) if (!is(T == U)) { T[n] output; for(size_t i = 0; i < n; i++) { output[i] = cast(T) a[i]; } return output; } } T[n] staticArray(T, ulong n) (auto ref T[n] a) {return a;} struct Foo { float x; T opCast(T)() { return cast(T) x; } } void main(){ auto a = [1,2,3].staticArray!float; pragma(msg, typeof(a)); // float[3] a.writeln(); [1,2,3].staticArray.writeln(); auto b = [1,2,3].staticArray!Foo; b.writeln(); }
This works fine, even in betterC mode with LDC. Doesn't work with betterC with DMD (https://issues.dlang.org/show_bug.cgi?id=19946). I still don't like the .staticArray, but I'll use it if this DIP isn't approved. Maybe `[$]` can be a shortcut to .staticArray.
Jan 06
prev sibling parent reply Luhrel <lucien.perregaux gmail.com> writes:
On Wednesday, 6 January 2021 at 18:34:31 UTC, Nick Treleaven 
wrote:
 On Wednesday, 6 January 2021 at 18:29:05 UTC, Nick Treleaven 
 wrote:
 Can be fixed (probably with another name):

 //import std.array;
Actually template overloading seems to work fine: template staticArray(T) { T[n] staticArray(ulong n) (auto ref T[n] a) {return a;} } T[n] staticArray(T, ulong n) (auto ref T[n] a) {return a;} void main(){ auto a = [1,2,3].staticArray!float; pragma(msg, typeof(a)); // float[3] a.writeln(); [1,2,3].staticArray.writeln(); }
Still doesn't work with `short`.
Jan 06
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 6 January 2021 at 19:17:46 UTC, Luhrel wrote:
 [snip]

 Still doesn't work with `short`.
Pretty sure my version above does.
Jan 06
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/6/21 1:14 PM, Luhrel wrote:
 On Wednesday, 6 January 2021 at 17:59:57 UTC, Jacob Carlborg wrote:
 On 2021-01-06 10:21, Mike Parker wrote:
 This is the discussion thread for the first round of Community Review 
 of DIP 1039, "Static Arrays with Inferred Length":

 https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7
969/DIPs/DIP1039.md 
There's `staticArray` to solve this issue [1]. [1] https://dlang.org/phobos/std_array.html#.staticArray
It works only for the `int` type and above (and other types as structs). example with short: --- extern(C) void main() {     import std.array;     auto a = [0, 1].staticArray!short;  // error } --- To fix that, I need to cast every element: --- extern(C) void main() {     import std.array;     auto a = [cast(short) 1, cast(short) 2].staticArray!short; // ok } ---
With a tweak, it's possible: T[n] staticArray(T, size_t n)(T[n] val...) { return val; } auto arr = staticArray!short(1, 2); Though the syntax isn't as nice... -Steve
Jan 07
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Wednesday, 6 January 2021 at 17:59:57 UTC, Jacob Carlborg 
wrote:
 There's `staticArray` to solve this issue [1].
It does a slightly different thing. staticArray works with types of literals and values, while the proposed way works with type of the declaration. Now you have to either infer the whole type (`auto`) or not infer anything at all. This proposal would let one to infer the length of a static array without inferring it's type. For example, `short[$] arr = [1,2,3]` isn't easily representable with `staticArray`, as `is(typeof([1,2,3].staticArray) == int[3])`. Whether the issues are different enough to justify a new language feature is another question though.
Jan 06
prev sibling next sibling parent reply Nick Treleaven <nick geany.org> writes:
 From the feedback thread:

On Wednesday, 6 January 2021 at 17:54:34 UTC, Dukc wrote:
 `std.array.staticArray` can already handle most of the problems 
 described, and it does work in betterC - I just tested with LDC 
 1.20.1 targeting WebAssembly. while there are remaining cases 
 (`auto fun(int[$] = [1,2,3])` isn't easy to represent now), I 
 suspect they are a bit too trivial to justify a new feature.
Type inference for parameters with a default argument could be made to work. auto fun(auto a = [1,2,3].staticArray) {return a;}
 On to refining the feature if it's accepted anyway. This should 
 work:
 ```
 int[$] bar(int[2] arr)              // Error: not allowed in 
 functions declarations
 {
     return arr ~ [3, 4];
 }
 ```
 Why? because you can use `auto` as return type. `Type[$]` 
 should IMO work anywhere `auto` does.
The inferred return type is int[], and causes an error if the return type is specified as int[4].
 You need to mention that this DIP will break code in this, 
 admittedly rare, case:
 ```
 int[] x = something;
 int y = something[0 .. staticArrFunc(cast(int[$])[1,2,3])];
 ```
Excellent point, but it isn't just casts, anywhere you use a type (template instantiation) that is within an indexing expression will have this problem.
 I wonder if `$` should be allowed inside an expression, like 
 this:
 ```
 int[$+2] a = [1,2,3]; //static array of [1,2,3,0,0]
 ```
Not worth it, easy to workaround.
Jan 06
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 6 January 2021 at 18:22:32 UTC, Nick Treleaven 
wrote:
 Type inference for parameters with a default argument could be 
 made to work.

 auto fun(auto a = [1,2,3].staticArray) {return a;}
Okay that was a bad example. But see Luhrels answer to Jacob.
 ```
 int[$] bar(int[2] arr)              // Error: not allowed in 
 functions declarations
 {
     return arr ~ [3, 4];
 }
 ```
causes an error if the return type is specified as int[4].
Why? `arr` is static so the compiler should be able to figure that no overflow will ever happen.
 ```
 int[] x = something;
 int y = something[0 .. staticArrFunc(cast(int[$])[1,2,3])];
 ```
Excellent point, but it isn't just casts, anywhere you use a type (template instantiation) that is within an indexing expression will have this problem.
Yeah, this is just the simplest example that came to mind.
Jan 06
parent reply Nick Treleaven <nick geany.org> writes:
On Wednesday, 6 January 2021 at 18:33:54 UTC, Dukc wrote:
 ```
 int[$] bar(int[2] arr)              // Error: not allowed in 
 functions declarations
 {
     return arr ~ [3, 4];
 }
 ```
causes an error if the return type is specified as int[4].
Why? `arr` is static so the compiler should be able to figure that no overflow will ever happen.
Because: 1. concatenation with a static array is not defined (use `arr[]`). 2. slices do not implicitly convert to a static array.
Jan 06
parent Dukc <ajieskola gmail.com> writes:
On Wednesday, 6 January 2021 at 18:41:31 UTC, Nick Treleaven 
wrote:
 On Wednesday, 6 January 2021 at 18:33:54 UTC, Dukc wrote:
 Why? `arr` is static so the compiler should be able to figure 
 that no overflow will ever happen.
Because: 1. concatenation with a static array is not defined (use `arr[]`).
Oh okay.
 2. slices do not implicitly convert to a static array.
They do if the length is known at compile time, but `~` does not for some reason propagate the length. This works though: ``` int[4] bar(int[2] arr) { return arr.conc([3, 4]); } T[i+j] conc(T, size_t i, size_t j)(T[i] a, T[j] b) { typeof(return) result; result[0 .. i] = a[]; result[i .. $] = b[]; return result; } ```
Jan 06
prev sibling parent reply Luhrel <lucien.perregaux gmail.com> writes:
On Wednesday, 6 January 2021 at 18:22:32 UTC, Nick Treleaven 
wrote:
 From the feedback thread:

 On Wednesday, 6 January 2021 at 17:54:34 UTC, Dukc wrote:
 `std.array.staticArray` can already handle most of the 
 problems described, and it does work in betterC - I just 
 tested with LDC 1.20.1 targeting WebAssembly. while there are 
 remaining cases (`auto fun(int[$] = [1,2,3])` isn't easy to 
 represent now), I suspect they are a bit too trivial to 
 justify a new feature.
Type inference for parameters with a default argument could be made to work. auto fun(auto a = [1,2,3].staticArray) {return a;}
I think that `int[$] a = [1, 2, 3]` is much more user-friendly. ``` auto a = [1,2,3].staticArray!ubyte ``` is way too complicated than simply ``` ubyte[$] a = [1,2,3]; ``` ... but that's my opinion.
 You need to mention that this DIP will break code in this, 
 admittedly rare, case:
 ```
 int[] x = something;
 int y = something[0 .. staticArrFunc(cast(int[$])[1,2,3])];
 ```
Excellent point, but it isn't just casts, anywhere you use a type (template instantiation) that is within an indexing expression will have this problem.
I don't get it. 1. `y` should be a int[]. 2. if staticArrFunc returns a size_t, then the problem can be simplified as: ``` staticArrFunc(cast(int[$])[1,2,3]); // no need to cast : staticArrFunc([1,2,3]); // already works like that (if staticArrFunc takes a int[3]) ```
 I wonder if `$` should be allowed inside an expression, like 
 this:
 ```
 int[$+2] a = [1,2,3]; //static array of [1,2,3,0,0]
 ```
Not worth it, easy to workaround.
I like this idea, even if there are workarounds.
Jan 07
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 7 January 2021 at 13:03:54 UTC, Luhrel wrote:
 I think that `int[$] a = [1, 2, 3]` is much more user-friendly.
 ```
 auto a = [1,2,3].staticArray!ubyte
 ```
But what prevents you from writing your own library solution that works like this? auto ints = mkarray(1,2,3,4,5); auto floats = mkarray(1.0f,2,3,4,5); etc
Jan 07
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 7 January 2021 at 13:03:54 UTC, Luhrel wrote:
 I don't get it.
 1. `y` should be a int[].
True - see my correction at the feedback theard.
 2. if staticArrFunc returns a size_t, then the problem can be 
 simplified as:
 ```
 staticArrFunc(cast(int[$])[1,2,3]); // no need to cast :
 staticArrFunc([1,2,3]); // already works like that (if 
 staticArrFunc takes a int[3])
 ```
If your DIP is implemented, what you say is true. But the point is that right now it means a different thing - a cast to static array of the length of `something` (in the full example), not to length of `[1,2,3]`. The point is that your DIP will silently change the behaviour of code like this. I do agree that this is such a rare enough occurence that we might be best off just accepting it. But it needs to be mentioned in the DIP.
Jan 07
parent reply Luhrel <lucien.perregaux gmail.com> writes:
On Thursday, 7 January 2021 at 15:27:09 UTC, Dukc wrote:
 On Thursday, 7 January 2021 at 13:03:54 UTC, Luhrel wrote:
 2. if staticArrFunc returns a size_t, then the problem can be 
 simplified as:
 ```
 staticArrFunc(cast(int[$])[1,2,3]); // no need to cast :
 staticArrFunc([1,2,3]); // already works like that (if 
 staticArrFunc takes a int[3])
 ```
If your DIP is implemented, what you say is true. But the point is that right now it means a different thing - a cast to static array of the length of `something` (in the full example), not to length of `[1,2,3]`. The point is that your DIP will silently change the behaviour of code like this.
I understand want do you mean, but we're currently unable to use the `$` operation from `something` inside a cast. ``` int staticArrFunc(int[6] a) { return a[0]; } void main() { int[] s = [1, 2, 3, 4, 5, 6]; int[] y = s[0 .. staticArrFunc(cast(int[$]) [1,2,3])]; // Error: CTFE internal error: trying to access uninitialized var } ``` Do you have a currently working example, that would potentially be broken by my DIP ?
 I do agree that this is such a rare enough occurence that we 
 might be best off just accepting it. But it needs to be 
 mentioned in the DIP.
I don't want a DIP that will break other people codes.
Jan 07
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 7 January 2021 at 15:58:24 UTC, Luhrel wrote:
 ```
 int staticArrFunc(int[6] a)
 {
     return a[0];
 }

 void main()
 {
     int[] s = [1, 2, 3, 4, 5, 6];
     int[] y = s[0 .. staticArrFunc(cast(int[$]) [1,2,3])];
     // Error: CTFE internal error: trying to access 
 uninitialized var
 }
 ```

 Do you have a currently working example, that would potentially 
 be broken by my DIP ?
It does not compile because length of `s` is not known at compile time. It SHOULD compile if `s` was either a static array or a manifest constant, but currently it does not - what a lucky bug! I still think it deserves a mention -it's standard practice to put the "breaking changes" section even if there are none. In this case it seems a breaking change by the spec, but not by the implementation.
Jan 08
next sibling parent Dukc <ajieskola gmail.com> writes:
On Friday, 8 January 2021 at 11:49:30 UTC, Dukc wrote:

 It SHOULD compile if `s` was either a static array or a 
 manifest constant, but currently it does not - what a lucky bug!
Bugzilla: https://issues.dlang.org/show_bug.cgi?id=16213
Jan 08
prev sibling parent reply Luhrel <lucien.perregaux gmail.com> writes:
On Friday, 8 January 2021 at 11:49:30 UTC, Dukc wrote:
 On Thursday, 7 January 2021 at 15:58:24 UTC, Luhrel wrote:
 [...]
It does not compile because length of `s` is not known at compile time. It SHOULD compile if `s` was either a static array or a manifest constant, but currently it does not - what a lucky bug! I still think it deserves a mention -it's standard practice to put the "breaking changes" section even if there are none. In this case it seems a breaking change by the spec, but not by the implementation.
Currently, isn't `$` only allowed inside the square brackets ? https://dlang.org/spec/arrays.html#array-length I don't think this bug is valid
Jan 08
parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 8 January 2021 at 12:43:51 UTC, Luhrel wrote:
 On Friday, 8 January 2021 at 11:49:30 UTC, Dukc wrote:
 On Thursday, 7 January 2021 at 15:58:24 UTC, Luhrel wrote:
 [...]
It does not compile because length of `s` is not known at compile time. It SHOULD compile if `s` was either a static array or a manifest constant, but currently it does not - what a lucky bug! I still think it deserves a mention -it's standard practice to put the "breaking changes" section even if there are none. In this case it seems a breaking change by the spec, but not by the implementation.
Currently, isn't `$` only allowed inside the square brackets ? https://dlang.org/spec/arrays.html#array-length I don't think this bug is valid
Yes, and it is inside square brackets - just not as the top-level expression. But no-one claimed it has to be top-level.
Jan 08
parent Luhrel <lucien.perregaux gmail.com> writes:
On Friday, 8 January 2021 at 14:02:03 UTC, Dukc wrote:
 On Friday, 8 January 2021 at 12:43:51 UTC, Luhrel wrote:
 [...]
Yes, and it is inside square brackets - just not as the top-level expression. But no-one claimed it has to be top-level.
Well, it's not specified in the doc, but every example uses it as a top-level expression. PS: It's a bit off-topic, but it may change my point of view.
Jan 08
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/6/21 4:21 AM, Mike Parker wrote:
 This is the discussion thread for the first round of Community Review of 
 DIP 1039, "Static Arrays with Inferred Length":
 
 https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7
969/DIPs/DIP1039.md 
 
 
 The review period will end at 11:59 PM ET on January 20, or when I make 
 a post declaring it complete. Discussion in this thread may continue 
 beyond that point.
 
 Here in the discussion thread, you are free to discuss anything and 
 everything related to the DIP. Express your support or opposition, 
 debate alternatives, argue the merits, etc.
 
 However, if you have any specific feedback on how to improve the 
 proposal itself, then please post it in the feedback thread. The 
 feedback thread will be the source for the review summary that I will 
 write at the end of this review round. I will post a link to that thread 
 immediately following this post. Just be sure to read and understand the 
 Reviewer Guidelines before posting there:
 
 https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
 
 And my blog post on the difference between the Discussion and Feedback 
 threads:
 
 https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/
 
 Please stay on topic here. I will delete posts that are completely 
 off-topic.
Should this be on the announce forum? -Steve
Jan 07
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 7 January 2021 at 21:26:28 UTC, Steven Schveighoffer 
wrote:

 Should this be on the announce forum?
No it shouldn't. But by the time I realized it was, the discussion was well underway.
Jan 07
prev sibling next sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote:
 https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md
A bit off topic: Would Kenji Hara still have been an active Dlang community member if his solution to DIP-1039 hadn't been reverted.
Jan 07
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 7 January 2021 at 21:42:55 UTC, Per Nordlöw wrote:
 On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote:
 https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md
A bit off topic: Would Kenji Hara still have been an active Dlang community member if his solution to DIP-1039 hadn't been reverted.
Please start a new thread for that and let's keep this one focused on this DIP. Thanks!
Jan 07
prev sibling parent reply Luhrel <lucien.perregaux gmail.com> writes:
 From the feedback thread:

On Friday, 8 January 2021 at 00:57:37 UTC, Q. Schroll wrote:
 The DIP massively fails to provide a good rationale why 
 std.array.staticArray is insufficient. It looks unpleasant, but 
 does the job in practically all cases demonstrated in the 
 examples a1 through a6.

 Example a1 currently doesn't work exactly because staticArray 
 returns immutable(char)[6], not char[6]. One needs a 
 char-specific function that is trivial to write:

     C[n] staticCharArray(C, size_t n)(auto ref const(C)[n] 
 charArray)
     {
         return charArray;
     }

 Then, example a1 can be written as:
     auto a1 = "cerise".staticCharArray;
     static assert(is(typeof(a1) == char[6]));

 Example a2 needs enum, but as long as someone knows what 
 they're doing, enum int[] is fine:
     enum int[] d = [1, 2, 3]; // enum instead of const
     auto a2 = d.staticArray;
     static assert(is(typeof(a2) == int[3]));

 Example a3 is straightforward the primary use case for 
 staticArray:
     auto a3 = [1,2,3].staticArray;

 Example a4 is, too.
     auto a4 = [[1,2].staticArray, [3, 4]];
     pragma(msg, typeof(a4)); // int[2][]
I really don't like the `.staticArray` because it's non-esthetic. I don't know if it's really argument, mainly because it's very personal.
 Example a5 is the first one that's actually painful to work 
 around:
     enum a5DefaultValue = [1,2].staticArray;
     void foo(typeof(a5DefaultValue) a5 = a5DefaultValue)
     {
         static assert(is(typeof(a5) == int[2]));
     }
 I think this is rather an argument for allowing type deducted 
 defaulted function parameters generally, not only static arrays.
Good point.
 Example a6 is the prime use-case for auto type deduction:
     int[2] bar() { return [1,2]; }
     auto a6 = bar();
     static assert(is(typeof(a6) == int[2]));
Correct. I'll rewrite this example. There should be a type conversion: ``` int[2] bar() { return [1,2]; } long[$] a6 = bar(); // implicit conversion static assert(is(typeof(a6) == long[2])); ``` Now it makes more sense.
 This feature would have a reasonable chance of being accepted 
 some years ago. Since this is the feedback thread, here's my 
 constructive feedback:

 A. You maybe need better examples. Ease of reading and writing 
 code can be an argument. You may want to state it somewhere. 
 Unfortunately, this isn't a very good one. If you can come up 
 with examples where workarounds are at least slightly more 
 unpleasant than the one for Example a5 (that don't look too 
 artificial), it might work out.
:scratching my head:
 B. The DIP says that int[2] and int[$] may end up the same 
 thing, but document different intent.
wtf. No ?
 IMO, this is the best argument this DIP has. An immediate case 
 where this is relevant is as a function return type. As an 
 example, opSlice (as the lowering of the double-dots in xs[0 .. 
 1]) returns size_t[2].
 It won't ever return another number of size_t, so size_t[$] 
 would be wrong conceptually. Other functions returning static 
 arrays might return T[4], but the 4 isn't particular to the use 
 case. If it might change, this can be documented using T[$] so 
 that uses of the function don't rely on the 4 too much.
 This is merely an example I came up with thinking for a minute.
The previous attempt was reverted because of control-flow analysis that was needed.
 There could be much better examples.
Yes.
 C. The DIP really must address the fact that what is gained is 
 very minor. Therefore, the difficulty of the implementation and 
 its maintenance in the compiler code plays a huge role.
I don't think, it's an old feature. Even BCPL had it.
 If you can provide an implementation that most people would 
 agree isn't that big of a deal having in the compiler, that 
 would be really valuable.
If I implement it, would people more agree with the DIP ? For me it's a nonsense (and a waste of time, if the DIP is not accepted).
Jan 08
parent reply Nick Treleaven <nick geany.org> writes:
On Friday, 8 January 2021 at 14:07:29 UTC, Luhrel wrote:
 Example a3 is straightforward the primary use case for 
 staticArray:
     auto a3 = [1,2,3].staticArray;
I really don't like the `.staticArray` because it's non-esthetic. I don't know if it's really argument, mainly because it's very personal.
The worst thing about it is you have to import std.array, so probably people won't bother scrolling to the top to add the import and losing/bookmarking their place, and will just count the items themselves. When it was originally proposed, it was in object.d. I think if the DIP proposed a literal syntax instead of a new variable declaration syntax, it would be much less of a burden to the compiler. I think we don't have any partial (variable) type inference syntax ATM.
 Correct. I'll rewrite this example.
 There should be a type conversion:

 ```
 int[2] bar() { return [1,2]; }
 long[$] a6 = bar();  // implicit conversion
 static assert(is(typeof(a6) == long[2]));
 ```
Error: cannot implicitly convert expression `bar()` of type `int[2]` to `long[]`
Jan 11
next sibling parent Nick Treleaven <nick geany.org> writes:
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
 ```
 int[2] bar() { return [1,2]; }
 long[$] a6 = bar();  // implicit conversion
 static assert(is(typeof(a6) == long[2]));
 ```
Error: cannot implicitly convert expression `bar()` of type `int[2]` to `long[]`
This is the error you get today if you write `long[2]` for the type of a6. (It's a bit confusing that `long[]` slice type is mentioned in the message).
Jan 11
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
 [snip]

 I think if the DIP proposed a literal syntax instead of a new 
 variable declaration syntax, it would be much less of a burden 
 to the compiler. I think we don't have any partial (variable) 
 type inference syntax ATM.
 [snip]
Could you provide an example? (apologies if you already have...)
Jan 11
parent reply Nick Treleaven <nick geany.org> writes:
On Monday, 11 January 2021 at 13:05:18 UTC, jmh530 wrote:
 On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven 
 wrote:
 [snip]

 I think if the DIP proposed a literal syntax instead of a new 
 variable declaration syntax, it would be much less of a burden 
 to the compiler. I think we don't have any partial (variable) 
 type inference syntax ATM.
 [snip]
Could you provide an example? (apologies if you already have...)
Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal.
Jan 11
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven wrote:
 [snip]

 Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var 
 =` with it as normal.
Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$). Of course, the typical response would be, "well why not use alias s = static array". I would ask what about an nogc unittest where the author is trying to limit calls to functions that aren't really central to what is being tested. The next best alternative is something like `enum immutable x = [1];` and then using `x`. Building that static array literal functionality into the compiler would be useful in that case.
Jan 11
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
 Of course, the typical response would be, "well why not use 
 alias s = static array". I would ask what about an  nogc 
 unittest where the author is trying to limit calls to functions 
 that aren't really central to what is being tested.
I've used std.array.staticArray for nogc unit tests. It works fine, and the fact that it has a descriptive name makes it a lot more readable than something like `[1, 2, 3]s`.
Jan 11
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 11 January 2021 at 21:33:36 UTC, Paul Backus wrote:
 On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
 Of course, the typical response would be, "well why not use 
 alias s = static array". I would ask what about an  nogc 
 unittest where the author is trying to limit calls to 
 functions that aren't really central to what is being tested.
I've used std.array.staticArray for nogc unit tests. It works fine, and the fact that it has a descriptive name makes it a lot more readable than something like `[1, 2, 3]s`.
I know it can be used. My main point was "where the author is trying to limit calls to functions that aren't really central to what is being tested". Consider nogc unittest { assert([1, 2]s.nogcFunction == value); } vs nogc unittest { import std.array: staticArray; assert([1, 2].staticArray.nogcFunction == value); } Not really different enough for me to care all that much, but the first one avoids the import and is a bit simpler. I didn't really feel that strongly about the DIP. My comment was more that if that literal syntax were adopted, I would use it. There's a lot of literals that I rarely make use of and have to look up what it is. If I see 1.05L, I'm like "how could that be a long?" Until I look it up and find out it's a real literal. However, I imagine that people out there do make use of these things (maybe not for reals so much, given the hate a lot of people give them, but other ones).
Jan 11
parent Paul Backus <snarwin gmail.com> writes:
On Monday, 11 January 2021 at 22:28:04 UTC, jmh530 wrote:
 On Monday, 11 January 2021 at 21:33:36 UTC, Paul Backus wrote:
 On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
 Of course, the typical response would be, "well why not use 
 alias s = static array". I would ask what about an  nogc 
 unittest where the author is trying to limit calls to 
 functions that aren't really central to what is being tested.
I've used std.array.staticArray for nogc unit tests. It works fine, and the fact that it has a descriptive name makes it a lot more readable than something like `[1, 2, 3]s`.
I know it can be used. My main point was "where the author is trying to limit calls to functions that aren't really central to what is being tested".
Yes, and my point is, staticArray is a well-tested standard-library function with an extremely simple implementation, so the odds of it introducing spurious faults into a unit test are essentially zero. So even though I always try to limit calls to unrelated functions in my unit tests, I consider staticArray safe to use.
Jan 11
prev sibling parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
 On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven 
 wrote:
 [snip]

 Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var 
 =` with it as normal.
Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$).
You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?)
Jan 12
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 12 January 2021 at 17:27:50 UTC, Q. Schroll wrote:
 On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
 On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven 
 wrote:
 [snip]

 Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto 
 var =` with it as normal.
Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$).
You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?)
Interesting approach! However, it doesn't really resolve my underlying issue, which was that I would still need to import that s struct.
Jan 12
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 12 January 2021 at 18:19:14 UTC, jmh530 wrote:
 On Tuesday, 12 January 2021 at 17:27:50 UTC, Q. Schroll wrote:
 On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
 On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven 
 wrote:
 [snip]

 Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto 
 var =` with it as normal.
Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$).
You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?)
Interesting approach! However, it doesn't really resolve my underlying issue, which was that I would still need to import that s struct.
To play the devil's advocate, it shouldn't be hard to change the compiler config file to auto-import any module of your choice (it config file would simply append it to the compiler command line). That said, for me the unnecessary template instances generated for each different type and array length is a bigger reason for me preferring this DIP proposal, over the library approach.
Jan 12
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 12 January 2021 at 19:27:31 UTC, Petar Kirov 
[ZombineDev] wrote:
 [snip]

 To play the devil's advocate, it shouldn't be hard to change 
 the compiler config file to auto-import any module of your 
 choice (it config file would simply append it to the compiler 
 command line).

 [snip]
That sounds a bit like magic, in the Arthur C. Clarke sense. Would that work in a project that other people are working on? (i.e., do they have to modify their compiler config files too?). I'd rather put the import at the top of the file, or in a version(unittest) block than that. The problem with those approaches is that if you have an example unittest, then when a user tries to run it then they have to put the import in themselves.
Jan 12
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 12 January 2021 at 19:49:10 UTC, jmh530 wrote:
 I'd rather put the import at the top of the file, or in a 
 version(unittest) block than that. The problem with those 
 approaches is that if you have an example unittest, then when a 
 user tries to run it then they have to put the import in 
 themselves.
Seems like the obvious solution is to put the import inside the unittest.
Jan 12
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 12 January 2021 at 20:04:00 UTC, Paul Backus wrote:
 On Tuesday, 12 January 2021 at 19:49:10 UTC, jmh530 wrote:
 I'd rather put the import at the top of the file, or in a 
 version(unittest) block than that. The problem with those 
 approaches is that if you have an example unittest, then when 
 a user tries to run it then they have to put the import in 
 themselves.
Seems like the obvious solution is to put the import inside the unittest.
I mean, I'm not chomping at the bit for it, or this DIP. If things stay as they are, then I'll keep doing what I'm doing.
Jan 12
prev sibling parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 12 January 2021 at 20:04:00 UTC, Paul Backus wrote:
 On Tuesday, 12 January 2021 at 19:49:10 UTC, jmh530 wrote:
 I'd rather put the import at the top of the file, or in a 
 version(unittest) block than that. The problem with those 
 approaches is that if you have an example unittest, then when 
 a user tries to run it then they have to put the import in 
 themselves.
Seems like the obvious solution is to put the import inside the unittest.
I'd say that example unit tests shouldn't have anything available except the current module. That a unittest is just a function is wrong in many ways. By default, it shouldn't have access to imports outside of it and it shouldn't have access to non-public (private, package) symbols.
Jan 12
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 12 January 2021 at 23:19:45 UTC, Q. Schroll wrote:
 On Tuesday, 12 January 2021 at 20:04:00 UTC, Paul Backus wrote:
 On Tuesday, 12 January 2021 at 19:49:10 UTC, jmh530 wrote:
 I'd rather put the import at the top of the file, or in a 
 version(unittest) block than that. The problem with those 
 approaches is that if you have an example unittest, then when 
 a user tries to run it then they have to put the import in 
 themselves.
Seems like the obvious solution is to put the import inside the unittest.
I'd say that example unit tests shouldn't have anything available except the current module. That a unittest is just a function is wrong in many ways. By default, it shouldn't have access to imports outside of it and it shouldn't have access to non-public (private, package) symbols.
Agreed. Hence why we had to workaround those language limitations in phobos with this: https://github.com/dlang/tools/blob/master/tests_extractor.d
Jan 12
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Tuesday, 12 January 2021 at 17:27:50 UTC, Q. Schroll wrote:
 On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
 Gotcha. I think I would use that more than the current DIP 
 (though I prefer [1]s to [1]$).
You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?)
Cool. I'd call it F for fixed size array, `F[e1,e2]`.
Jan 13
parent Q. Schroll <qs.il.paperinik gmail.com> writes:
On Wednesday, 13 January 2021 at 15:40:35 UTC, Nick Treleaven 
wrote:
 On Tuesday, 12 January 2021 at 17:27:50 UTC, Q. Schroll wrote:
 On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
 Gotcha. I think I would use that more than the current DIP 
 (though I prefer [1]s to [1]$).
You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?)
Cool. I'd call it F for fixed size array, `F[e1,e2]`.
[rant] Calling T[n] an array is correct and useful. In my opinion, calling T[] an array is wrong, not even imprecise, plain wrong. It's a slice: a typed part of memory that may overlap with arrays and other slices, potentially even typed differently. "Array" gives one, at least it gives me, a wrong impression how the object behaves. Have you seen overlapping "arrays" in any other language? I have not. Calling T[] an array (sometimes) is the biggest didactic mistake the D community makes. That way, it is unnecessarily hard to learn the concept for anyone who already has an idea what an array is. [/rant]
Jan 13
prev sibling next sibling parent reply Luhrel <lucien.perregaux gmail.com> writes:
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
 On Friday, 8 January 2021 at 14:07:29 UTC, Luhrel wrote:
 Example a3 is straightforward the primary use case for 
 staticArray:
     auto a3 = [1,2,3].staticArray;
I really don't like the `.staticArray` because it's non-esthetic. I don't know if it's really argument, mainly because it's very personal.
The worst thing about it is you have to import std.array, so probably people won't bother scrolling to the top to add the import and losing/bookmarking their place, and will just count the items themselves. When it was originally proposed, it was in object.d.
Yep, I introduced this DIP because I had to count the number of elements in my array (I'm lazy).
 I think if the DIP proposed a literal syntax instead of a new 
 variable declaration syntax, it would be much less of a burden 
 to the compiler. I think we don't have any partial (variable) 
 type inference syntax ATM.
I don't think that will be complicated to implement, the compiler already says "mismatched array lengths, 2 and 1".
 Correct. I'll rewrite this example.
 There should be a type conversion:

 ```
 int[2] bar() { return [1,2]; }
 long[$] a6 = bar();  // implicit conversion
 static assert(is(typeof(a6) == long[2]));
 ```
Error: cannot implicitly convert expression `bar()` of type `int[2]` to `long[]`
Meh, gonna review my examples. ``` int[] bar() { return [1,2]; } int[$] a6 = bar(); // conversion from int[] to int[2] static assert(is(typeof(a6) == int[2])); ``` When manually replacing $ by 2, it now works as excepted.
Jan 11
next sibling parent Luhrel <lucien.perregaux gmail.com> writes:
On Monday, 11 January 2021 at 20:25:14 UTC, Luhrel wrote:
 Meh, gonna review my examples.


 ```
 int[] bar() { return [1,2]; }
 int[$] a6 = bar();  // conversion from int[] to int[2]
 static assert(is(typeof(a6) == int[2]));
 ```
 When manually replacing $ by 2, it now works as excepted.
In fact, this shouldn't work with my DIP. It's too much work for the compiler.
Jan 11
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Monday, 11 January 2021 at 20:25:14 UTC, Luhrel wrote:
 I think if the DIP proposed a literal syntax instead of a new 
 variable declaration syntax, it would be much less of a burden 
 to the compiler. I think we don't have any partial (variable) 
 type inference syntax ATM.
I don't think that will be complicated to implement, the compiler already says "mismatched array lengths, 2 and 1".
Ok, you're right. I still think a literal syntax is the more natural way to do this though.
Jan 13
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote:
 On Friday, 8 January 2021 at 14:07:29 UTC, Luhrel wrote:
 Example a3 is straightforward the primary use case for 
 staticArray:
     auto a3 = [1,2,3].staticArray;
I really don't like the `.staticArray` because it's non-esthetic. I don't know if it's really argument, mainly because it's very personal.
The worst thing about it is you have to import std.array, so probably people won't bother scrolling to the top to add the import and losing/bookmarking their place,
Why do they have to scroll to the top? Even if they did, what editor are they using that they can't jump back to where they were?
Jan 13
parent reply Nick Treleaven <nick geany.org> writes:
On Wednesday, 13 January 2021 at 14:48:07 UTC, Atila Neves wrote:
 Why do they have to scroll to the top?
They don't, you're right. But if you want to use it throughout the module you need a top-level import, by convention at the top. Also the convention seems to be to put a local import at the start of a scope rather than sandwiched in the middle of statements.
 Even if they did, what editor are they using that they can't 
 jump back to where they were?
Geany. You can set a marker but probably the editor should automatically add to location history before the go to start of file key binding is executed.
Jan 13
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 13 January 2021 at 15:31:33 UTC, Nick Treleaven 
wrote:
 On Wednesday, 13 January 2021 at 14:48:07 UTC, Atila Neves 
 wrote:
 Why do they have to scroll to the top?
They don't, you're right. But if you want to use it throughout the module you need a top-level import, by convention at the top. Also the convention seems to be to put a local import at the start of a scope rather than sandwiched in the middle of statements.
Yes. 1. Save point 2. Jump to start of function 3. Write local import 4. Jump back More work than not having to do anything, obviously, but still.
Jan 13
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 13 January 2021 at 15:31:33 UTC, Nick Treleaven 
wrote:
 On Wednesday, 13 January 2021 at 14:48:07 UTC, Atila Neves 
 wrote:
 Even if they did, what editor are they using that they can't 
 jump back to where they were?
Geany. You can set a marker but probably the editor should automatically add to location history before the go to start of file key binding is executed.
I use Geany, and I'm no power user, I don't know many key bindings. My way to deal with this is dead stupid: I leave the character cursor where I am and start scrolling. When I want to go back, lArrow rArrow lArrow rArrow... The screen jumps back to the cursor. Then I scan the screen to see the cursor. It is much easier to spot when I keep it moving with the arrows.
Jan 14
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 14 January 2021 at 15:14:36 UTC, Dukc wrote:
 I use Geany, and I'm no power user, I don't know many key 
 bindings. My way to deal with this is dead stupid: I leave the 
 character cursor where I am and start scrolling. When I want to 
 go back, lArrow rArrow lArrow rArrow...
Oh didn't realize you were talking about scrolling to edit, not just to look. In the case of adding an import a though, there should usually be a start of lexical scope close enough to fit in the same screen with the invocation. Except when adding top-level symbols... I reckon I'd just memoize the line number roughly before scrolling.
Jan 14
parent Paul Backus <snarwin gmail.com> writes:
On Thursday, 14 January 2021 at 15:30:12 UTC, Dukc wrote:
 On Thursday, 14 January 2021 at 15:14:36 UTC, Dukc wrote:
 I use Geany, and I'm no power user, I don't know many key 
 bindings. My way to deal with this is dead stupid: I leave the 
 character cursor where I am and start scrolling. When I want 
 to go back, lArrow rArrow lArrow rArrow...
Oh didn't realize you were talking about scrolling to edit, not just to look. In the case of adding an import a though, there should usually be a start of lexical scope close enough to fit in the same screen with the invocation. Except when adding top-level symbols... I reckon I'd just memoize the line number roughly before scrolling.
https://www.geany.org/manual/current/#bookmarks TL;DR version: Ctrl-M : create or remove bookmark at current line (mnemonic: M for "mark") Ctrl-, : jump to previous bookmark (mnemonic: on the same key as "<") Ctrl-. : jump to next bookmark (mnemonic: on the same key as ">")
Jan 14