On Sunday, 17 July 2022 at 16:33:29 UTC, Nick Treleaven wrote:
> On Sunday, 17 July 2022 at 15:23:45 UTC, Steven Schveighoffer wrote:
> The second statement is much better, but you need the first to infer the length. Just specifying "infer the length" with a [$] on the type is a perfect fit.
There may be ambiguity with $ for length inside an index/slice expression when an inferred static array type is part of an expression:
https://forum.dlang.org/post/qsjahatdiyxwojcwyedm@forum.dlang.org
It would not be ambiguous, as int[$] would refer to the new type.
I'm having a hard time believing that kind of expression is currently used anywhere.
it would be consistent with using $ inside an expression of 2 nested arrays:
int[] arr;
int[] foo;
return arr[0 .. foo[$-1]]; // does $ refer to arr.length or foo.length?
> > You also have an issue with const conversion that's not as easy to specify. e.g.:
char[74] foo = "this is a long string that I don't want to have to count the characters in";
Presumably length inference would not include the terminating nul byte of the string literal?
Of course, that's not actually included in the literal length. e.g. "".length == 0.
> > Can't use staticArray here because the type will be immutable(char)[74].
If I want to specify it should be char, I can't do staticArray!char, because then it doesn't infer anything.
Could add an overload for that:
https://forum.dlang.org/post/urzdeerfcvardyztxfab@forum.dlang.org
Fair point (if anything could someone create an issue on this so it's not forgotten?). But I still think the nested syntax isn't good.
> > This is a simple quality-of-life improvement. I think the original PR was reverted because it allowed too much inference, like:
auto[$] foo = [1,2,3,4];
I think just specifying the length is dependent on the length of the literal is enough benefit to justify the change. We don't need full inference of any static array type.
Threads like these always use basic element types like int or char. In practice the element type can be quite complex. It's a pain to have to write out a complex type - e.g. typeof(x.map!(a => someExpr).front).
The use case for this escapes me. You can't do this with staticArray anyway.
auto x = arr.map!(a => a * 2).array.staticArray; // error, can't pass Something[] to staticArray
So current code that might build such a thing isn't any worse off with the feature.
What you need to write for this use case is a complex voldemort-type-producing expression, and then make multiple calls to that thing, inside an array expression. I just don't see it being a thing.
> That could be solved by having specific syntax for static array literals:
auto sa = $[1,2,3,4];
Maybe, maybe not. Yes, without a special syntax on the right side, you'd need a type for it, but I don't see a really convincing use case for this.
That being said, I would be ok with this syntax, or something that's identified on the expression. Hell, even if it was __staticArray(expr), that would be at least a possible solution.
> That avoids supporting partial auto declarations (a reason why Walter didn't like that PR).
That PR discussion is... interesting. I don't know exactly what the rejection was, aside from "this will just release the floodgates of crappy feature requests".
> It also allows inference when passing a literal to a template function argument where the parameter is not already a static array. The $[] syntax would literally mean "length array", i.e. fixed length array.
I'm not opposed to it exactly. But it does suffer the same problems as staticArray. It is sometimes nice to use the left-hand-side of the construction/assignment to determine how the literal is interpreted.
> (Why do we overload the word 'static' here for arrays?)
I hate that they are called "static" arrays also. fixedLengthArray is probably not a great function name though.
> And it's prefix syntax, which would read well with your nested static array example:
auto foo = $[$[1,2,3,4],[5,6,7,8]];
It doesn't help your char[$] foo = "immutable data"; case though (which would need the staticArray overload or equivalent).
Oh yeah, agreed. Maybe something can be done about that in the syntax, like $char[...] I don't know.
-Steve
Permalink
Reply
