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
Isue 4424 & 6216 Relax opAssign signature #166
Conversation
I would be really interested in this request going through as Issue 4424 seriously affects the interface of my GSoC project. |
A workaround exists against Issue 4424 like follows: struct X { private mixin template _workaround4424() { @disable void opAssign(typeof(this) ); } mixin _workaround4424; void opAssign(R)(R rhs) { /*...*/ } } It is already used std.typecons.Tuple. |
Add @Property to std.bitmanip
Update patch. |
Updated to fix 4596. |
I hit this issue in msgpack-d today. This patch is needed for correct implementation. |
This pull also contains a fix for bug 6336. |
Would it be possible to break this up a bit to make it easier to review and merge? |
@yebblies: As far as I can see, the pull request is already broken up into atomic commits?! |
After excluding unittests this pull isn't THAT big, but still I think @yebblies is right here. |
@klickverbot It's easier if I can review once bugfix at a time. Is each commit completely independent of the others? If so, it will be fairly easy to split them into multiple pull requests. If not I'll need to work out how they are related before I can be confident enough to pull them. |
Class type that has identity opAssign is disallowed both it is templated or not.
…ld's opAssign Separate 'top assignable' (see opAssign first) from 'blit assignable' (memberwise), and now they are not related to 'modifiable' directly.
Remove fail7695.d, because it was incorrectly failed to compile by bug 6336.
Improve checking of whether an expression is modifiable. If an expression is *initializing*, that is part of construction, then it bypass type check.
Later commits depends on early ones, and all of them are related to the assignable language semantics. |
Updated. |
This seems to be causing some failures in std.container |
The error in std.container is fixed by the change for 6174... |
Fair enough. |
Isue 4424 & 6216 Relax opAssign signature
I opened #1169 for issue 4596. |
|
||
Lassignerr: | ||
if (fd && !(fd->storage_class & STCdisable)) | ||
error("identity assignment operator overload is illegal"); |
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.
Why would you allow to explicitly @disable
the operator if it is illegal anyhow?
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.
Because @disable opAssign
can disallow class reference rebinding. If we allow normal opAssign for class types, it will cause null dereference if assigned class reference is null. On the other hand, disabled opAssign is always checked in compile time and no runtime error happens. I thought it would be useful.
This change is based on #94 (already merged).Issue 4424 - Copy constructor and templated opAssign cannot coexist
Issue 6174 - Initialize const fixed-size array in constructor
Issue 6216 - Built-in opAssign implicitly defined should call field's opAssign
Issue 6336 - Can't return ref T where T has const/immutable members
Following is removed from this pull request:
Issue 4596- [tdpl] Rebinding this in class method compiles