October 16, 2022

On Saturday, 15 October 2022 at 10:31:16 UTC, matheus wrote:

>

On Friday, 14 October 2022 at 20:19:20 UTC, Ali Çehreli wrote:

>

...
The compiler does not perform detailed analysis of all code. Since that 5 could be a runtime expression, the compiler does not check it at compile time.
...

Yes but in this case it's known during the compiling time (Literal 5), couldn't this be checked a prevented?

Matheus.

It could. And it's not hard to add it but I'm not sure it would be accepted.

We should instead deprecate

’’’d
new T[n]
’’’

in favor of

’’’d
new T
’’’

.

October 16, 2022

On Sunday, 16 October 2022 at 20:26:58 UTC, Per Nordlöw wrote:

>

On Saturday, 15 October 2022 at 10:31:16 UTC, matheus wrote:

>

On Friday, 14 October 2022 at 20:19:20 UTC, Ali Çehreli wrote:

>

...
The compiler does not perform detailed analysis of all code. Since that 5 could be a runtime expression, the compiler does not check it at compile time.
...

Yes but in this case it's known during the compiling time (Literal 5), couldn't this be checked a prevented?

The main problem in the OP example is that: mixing pointer/reference types and value types in the same assignment statement, and the compiler didn't complain.

I just logged an issue, and think we should deprecate it:

https://issues.dlang.org/show_bug.cgi?id=23420

>

It could. And it's not hard to add it but I'm not sure it would be accepted.

We should instead deprecate

October 16, 2022

On Sunday, 16 October 2022 at 20:26:58 UTC, Per Nordlöw wrote:

I meant we should instead deprecate

new T[n]

in favor of

new T[](n)

to avoid the syntactic confusion.

1 2 3 4
Next ›   Last »