On Saturday, 11 June 2022 at 10:52:58 UTC, Mike Parker wrote:
I agree with your initial assessment that it should be an
error. It really only makes sense to allow the dynamic
allocation if the fields are immutable and, in the case of
arrays, the initializer is a literal.
On Saturday, 11 June 2022 at 10:37:30 UTC, Bastiaan Veelo wrote:
So that’s why I used “why” in the title of this thread, which I
haven’t seen an answer to yet. What is the practical case where
that warning would be annoying? When would you actually want
this behaviour?
After actually
On Saturday, 11 June 2022 at 01:52:58 UTC, Mike Parker wrote:
People getting bit by `new` in field initialization often
enough that I think a warning would be helpful.
The problem is so much bigger because it is not just a case of
being aware not to use `new` in member initialisers. As you
On Saturday, 11 June 2022 at 02:22:28 UTC, matheus wrote:
Well would this be annoying? Yes, mainly if I already know
this, but if not, then it would be like a nice to know warning
for newbies like myself. By the way this would be only in the
cases that a static array field being initialized
On Saturday, 11 June 2022 at 01:52:58 UTC, Mike Parker wrote:
...
That's because static arrays are allocated as part of the
instance:
...
Yes I understood the problem, but the naive me was thinking that
in this example:
struct S{
int[] arr = new int[](5);
}
For some reason this would
On Saturday, 11 June 2022 at 01:14:06 UTC, matheus wrote:
So, in the case of "int[] arr = new int[](5)", an array of
length 5 of type int will be instantiated and its address will
be shared among whoever instantiates "S" and be pointed and
accessed through arr.
In the second case, "int[2]
On Friday, 10 June 2022 at 07:49:43 UTC, Mike Parker wrote:
...
And it *is* documented:
Struct fields are by default initialized to whatever the
Initializer for the field is, and if none is supplied, to the
default initializer for the field's type.
The default initializers are evaluated at
On Friday, 10 June 2022 at 14:56:24 UTC, Steven Schveighoffer
wrote:
On 6/10/22 3:46 AM, Mike Parker wrote:
I think this is a case where having a warning that's on by
default, and which can be explicitly disabled, is useful.
"Blah blah .init blah blah. See link-to-something-in-docs. Is
this
On 6/10/22 1:20 PM, Mike Parker wrote:
On Friday, 10 June 2022 at 14:56:24 UTC, Steven Schveighoffer wrote:
Discovered circa 2009: https://issues.dlang.org/show_bug.cgi?id=2947
It should be illegal to declare a field this way that has mutable
references without being `shared`. End of story.
On Friday, 10 June 2022 at 14:56:24 UTC, Steven Schveighoffer
wrote:
Discovered circa 2009:
https://issues.dlang.org/show_bug.cgi?id=2947
It should be illegal to declare a field this way that has
mutable references without being `shared`. End of story.
-Steve
The docs do say that:
The
On 6/10/22 3:46 AM, Mike Parker wrote:
On Friday, 10 June 2022 at 07:35:17 UTC, Bastiaan Veelo wrote:
Is there a use case where this makes sense? I would have much
appreciated the compiler slapping me on the fingers, but it doesn't. I
understand that it is safe and that the compiler can allow
On 10/6/22 14:58, Salih Dincer wrote:
On Friday, 10 June 2022 at 07:35:17 UTC, Bastiaan Veelo wrote:
I have been foolish enough to make a mistake like this:
```d
struct S
{
int[] arr = new int[](5);
}
```
Well, if the b's may not be equal, there's a simple solution. But why
are a's like
On Friday, 10 June 2022 at 07:35:17 UTC, Bastiaan Veelo wrote:
I have been foolish enough to make a mistake like this:
```d
struct S
{
int[] arr = new int[](5);
}
```
Well, if the b's may not be equal, there's a simple solution.
But why are a's like that, they're not static!
```d
void
On Friday, 10 June 2022 at 07:49:43 UTC, Mike Parker wrote:
And it *is* documented:
Struct fields are by default initialized to whatever the
Initializer for the field is, and if none is supplied, to the
default initializer for the field's type.
The default initializers are evaluated at
On Friday, 10 June 2022 at 07:46:36 UTC, Mike Parker wrote:
On Friday, 10 June 2022 at 07:35:17 UTC, Bastiaan Veelo wrote:
Is there a use case where this makes sense? I would have much
appreciated the compiler slapping me on the fingers, but it
doesn't. I understand that it is safe and that
On Friday, 10 June 2022 at 07:46:36 UTC, Mike Parker wrote:
I think this is a case where having a warning that's on by
default, and which can be explicitly disabled, is useful. "Blah
blah .init blah blah. See link-to-something-in-docs. Is this
what you intended?"
And it *is* documented:
On Friday, 10 June 2022 at 07:35:17 UTC, Bastiaan Veelo wrote:
Is there a use case where this makes sense? I would have much
appreciated the compiler slapping me on the fingers, but it
doesn't. I understand that it is safe and that the compiler can
allow this, but why would anyone want that?
17 matches
Mail list logo
