dlang.org
dlang.org copied to clipboard
Revert "Added a note to the doc saying that the feature is not yet implemented."
This reverts commit 8b96e90cd7afb965ab908dfe24b6df1514dbc702.
Static Initialization of AAs is implemented in D. This note is misleading and people can interpret this wrongly.
Signed-off-by: Luís Ferreira [email protected]
Reference-to: #2623
In fact, this code doesn't work on global scope:
immutable long[string] aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];
unittest
{
assert(aa["foo"] == 5);
assert(aa["bar"] == 10);
assert(aa["baz"] == 2000);
}
But inside a function, static initialization perfectly works:
void main() {
immutable long[string] aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];
assert(aa["foo"] == 5);
assert(aa["bar"] == 10);
assert(aa["baz"] == 2000);
}
The example code could be changed to reflect the working example and this should be rather an issue.
Thanks for your pull request and interest in making D better, @ljmf00! We are looking forward to reviewing it, and you should be hearing from a maintainer soon. Please verify that your PR follows this checklist:
- My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
- My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
- I have provided a detailed rationale explaining my changes
- New or modified functions have Ddoc comments (with
Params:
andReturns:
)
Please see CONTRIBUTING.md for more information.
If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.
Bugzilla references
Your PR doesn't reference any Bugzilla issue.
If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.
Your example doesn't show static initialization. That's a runtime function call and thus a dynamic initialization.
Your example doesn't show static initialization. That's a runtime function call and thus a dynamic initialization.
Sure, it uses the runtime under the hood.
If you take this example:
void main() {
enum long[string] aa = [
"foo": 5,
"bar": 10,
"baz": 2000
];
assert(aa["foo"] == 5);
assert(aa["bar"] == 10);
assert(aa["baz"] == 2000);
}
It works because of CTFE. Surely it's not completed, but my point here is maybe changing the spec to reflect the actual behavior because, AFAIK, this syntax is only shown here and it's misleading and misunderstood by many people.
The way I like to phrase it to people is AA's can't cross the divide between compile time and run time. You can use them in CTFE, you can use them in runtime execution contexts, you just can't construct one at compile time then use it at run time (or obviously not vice versa).
The example inside a function works since that's all runtime context. Outside the function though, the initializer is run at CT and the variable is RT, so that's the divide it can't cross.
And this is indeed just an implementation limitation.
I do agree the wording should be clearer just I don't think deleting it without more examples and/or explanation is the right thing to do.
ping @ljmf00
Hi,
ping @ljmf00
Thanks for pinging me.
I'm so sorry for leaving my contributions hanging in dlang, dlang-community and dlang-tour organizations. I have a lot of contributions pending actually and I'm so sorry for that, but I've been not so motivated to contribute to open-source during my final course year as it leads me to some overwelming and a lot of work to do. Although I want to keep contributing, as soon as I'm free from my school assessments, and be more active in the community but right now my brain is not capable of handling such external tasks.
Anyway, I added a commit.
Thanks @ljmf00 . No worries, hope you will get back once your timetable loosens up.
Thanks @ljmf00 . No worries, hope you will get back once your timetable loosens up.
I can discuss this on my free times tho, but don't expect me to answer quickly.
@maxhaton care to re-review?