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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
parent reply 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 2021
parent russhy <russhy gmail.com> writes:
Please make it happen!
May 15 2021