This repository was archived by the owner on Oct 12, 2022. It is now read-only.
Revert PR 2194 - Don't needlessly import everything in object.d when compiling with -betterC#2208
Merged
dlang-bot merged 1 commit intodlang:masterfrom Jun 10, 2018
JinShil:revert_betterc_import_reduction
Merged
Revert PR 2194 - Don't needlessly import everything in object.d when compiling with -betterC#2208dlang-bot merged 1 commit intodlang:masterfrom JinShil:revert_betterc_import_reduction
dlang-bot merged 1 commit intodlang:masterfrom
JinShil:revert_betterc_import_reduction
Conversation
Contributor
|
Thanks for your pull request, @JinShil! 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. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub fetch digger
dub run digger -- build "master + druntime#2208" |
jacob-carlborg
approved these changes
Jun 4, 2018
Geod24
approved these changes
Jun 4, 2018
Member
Geod24
left a comment
Geod24
left a comment
There was a problem hiding this comment.
LGTM
Could you add the PR description as commit message ? It is very informative and would be more accessible this way.
…compiling with -betterC The problem is not actually with PR 2194 per se, but rather with a fundamental design flaw in D: There is no way to determine which code is needed at compile-time and which code that is needed at runtime. Users of -betterC may wish to employ features of D at compile-time that are not available in the -betterC subset of the language at runtime. An obvious example is pragma(msg, typeid(size_t));. That code, as ridiculous as it is, is currently possible in -betterC despite the fact that it requires TypeInfo which is a feature not available in -betterC at runtime. If users are doing such things in -betterC, then #2194 will introduce regressions. #2194 should have actually been implemented at the time -betterC was first introduced, but we're past that point now. To resolve this issue in a more prudent manner, we either need to decide that compile-time -betterC and runtime -betterC must have feature parity, or we need to add a version(CTFE) feature to the language to segregate compile-time features and runtime features. This is actually a general cross-compilation issue: Users may want to have features of D available at compile-time that are not supported by their runtime target. But that's not a battle I'm prepared to fight at this time.
Contributor
Author
done |
wilzbach
approved these changes
Jun 10, 2018
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It is with great disappointment that I must revert #2194, which reduced imports in object.d when compiling with -betterC to just the language features supported by that subset of the language.
The problem is not actually with that PR per se, but rather with a fundamental design flaw in D: There is no way to determine which code is needed at compile-time and which code is needed at runtime.
Users of -betterC may wish to employ features of D at compile-time that are not available in the -betterC subset of the language at runtime. An obvious example is
pragma(msg, typeid(size_t));. That code, as ridiculous as it is, is currently possible in -betterC despite the fact that it requiresTypeInfowhich is a feature not available in -betterC at runtime. If users are doing such things in -betterC, then #2194 will introduce regressions. #2194 should have actually been implemented at the time -betterC was first introduced, but we're past that point now.To resolve this issue in a more prudent manner, we either need to decide that compile-time -betterC and runtime -betterC must have feature parity, or we need to add a
version(CTFE)feature to the language to segregate compile-time features and runtime features. This is actually a general cross-compilation issue: Users may want to have features of D available at compile-time that are not supported by their runtime target. But that's not a battle I'm prepared to fight at this time.object.d is a complete mess, and github's diff algorithm is not able to understand it, so relocating code back to their original locations and fixing indentations will turn this PR's diff into a monstrosity, as demonstrated by #2194's diff. Therefore, I'm leaving implementations where they are and just reverting the
version(D_BetterC)andversion(No_BetterC)scopes so reviewers will have an easier time reviewing. I can always submit future PRs to adjust the formatting and code locations if necessary.I'm sorry for the noise; it's part of the process when developing experimental features and learning the corner cases.