-
Notifications
You must be signed in to change notification settings - Fork 86
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
remove prohibition of unmanaged constructed types #604
remove prohibition of unmanaged constructed types #604
Conversation
1ac0cd3
to
629b005
Compare
629b005
to
0e19e09
Compare
rebased on the latest draft v8 branch on 9/26/2023 |
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.
This LGTM @RexJaeschke
I'm happy to merge at the next meeting.
The title talks about unmanaged constructed types - the text seems to be about pointer types. (It looks like constructed types still count as managed.) |
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.
Added one possible suggestion.
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.
One comment added in context as its in the range of the changes.
Lines 515, 617 & 699 probably also need to be changed. Also need to consider the unmanaged_type grammar (line 693), should it now allow a type parameter with the unmanaged constraint?
(@jskeet to have another pass at this - in this PR.) |
And look for other places, e.g. 515. |
Also (try to) remove the grammar as type parameters can be unmanaged - instead, make references to it specify that the type must be unmanaged. (Do this in a separate commit.) |
We should talk about this again - I'm finding it hard to get my head back into it, so when we talk, let's make verbose notes. |
The latest merge has undone all the changes here... suggest we revert the last commit. |
c155346
to
be915bc
Compare
OK, I went through the merge, tried to revert and that failed to make any sensible changes (the only change left was the revert of the links for the "pointer" restriction. Tried a rebase as well, and the same issue remained. I've tried looking at a reflog and I can't find the actual changes there either. |
This is the only change I could find.
Here's the original proposal as an issue in C# lang: dotnet/csharplang#1504 And the championed issue is here: dotnet/csharplang#1744 Finally, this issue contains some notes and details: dotnet/csharplang#1937 |
No description provided.