-
-
Notifications
You must be signed in to change notification settings - Fork 378
Revert "Added a note to the doc saying that the feature is not yet implemented." #2946
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
…plemented." This reverts commit 8b96e90. Static Initialization of AAs is implemented in D. This note is misleading and people can interpret this wrongly. Signed-off-by: Luís Ferreira <contact@lsferreira.net>
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 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 referencesYour 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. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nonetheless, thanks (I had never read this part of the spec)
@@ -337,8 +337,6 @@ $(H2 $(LNAME2 advanced_updating, Advanced updating)) | |||
|
|||
$(H2 $(LNAME2 static_initialization, Static Initialization of AAs)) | |||
|
|||
NOTE: Not yet implemented. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Firstly, "not yet implemented" is terrible for a language specification - so getting rid of it is good.
This behaviour needs to be better described - also a note on the word behaviour: In the context of a language specification the aim is not to describe what the language does in reality, but what it should do in order for it to be consistent in some desirable way.
https://dlang.org/spec/declaration.html#global_static_init The spec declares that this behaviour should be implemented for D to be compliant with its own specification in the sense that this declaration should be evaluable at compile time - in this case the expression is evaluable but for whatever (druntime) reason cannot be assigned to anything global or static.
The behaviour needs to be elaborated upon and the non-compliance noted in a more concrete way with an example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I elaborated a bit more, similarly to static initialization of normal arrays. I also added a more elaborated note about not being implemented on dmd compiler.
ping @ljmf00 |
… arrays Signed-off-by: Luís Ferreira <contact@lsferreira.net>
Hi,
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. |
I can discuss this on my free times tho, but don't expect me to answer quickly. |
@maxhaton care to re-review? |
This reverts commit 8b96e90.
Static Initialization of AAs is implemented in D. This note is misleading and
people can interpret this wrongly.
Signed-off-by: Luís Ferreira contact@lsferreira.net
Reference-to: #2623
In fact, this code doesn't work on global scope:
But inside a function, static initialization perfectly works:
The example code could be changed to reflect the working example and this should be rather an issue.