Please make it happen!
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
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
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
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
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
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:
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
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
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.
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
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,
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,
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
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]
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`.
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
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
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
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
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.
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
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,
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.
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
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.
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
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
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
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.
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
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
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
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
}
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.
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
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.
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/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md
The review period will end at 11:59 PM
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":
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
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 :
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
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
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
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.
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]
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]
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
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
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)
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,
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
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
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[$] =
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":
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
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/qglydztoqxhhcurvb...@forum.dlang.org
Why
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/qglydztoqxhhcurvb...@forum.dlang.org
Why not "int[auto] arr = [1, 2, 3]" ?
IMHO auto keyword is less ambiguous
On Wednesday, 6 January 2021 at 09:24:28 UTC, Mike Parker wrote:
The Feedback Thread is here:
https://forum.dlang.org/post/qglydztoqxhhcurvb...@forum.dlang.org
Why not "int[auto] arr = [1, 2, 3]" ?
IMHO auto keyword is less ambiguous than $.
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
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
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
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?
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
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
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:
//
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
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
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
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?
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:
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
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
73 matches
Mail list logo
