Merged the dependent names and using universal templates in code #32
Conversation
These sections had some overlap and I think the rules proposed regarding dependnet names in the "using universal templates in code" section overly complicated things. What I propose instead is to modify the dependnet name rules to promote dependnet names to universal template parameters in the narrow context of dependnet names used as template arguments (see text for detailed explanation). By making universal template parameters only be parsed as universal templates in this narrow context and unifying other dependent names to have this behavior, a lot of issues can be avoided.
| @@ -191,7 +191,7 @@ Here #2 fails late at #1 and #3 succeeds just as for the easy definition. | |||
|
|
|||
| ## Mechanism | |||
|
|
|||
| #### Additional possibilities offered by late ckecing | |||
| #### Additional possibilities offered by late checking | |||
There was a problem hiding this comment.
I think I have removed the notion of late checking. If it still there in main branch now that's a mistake. But you did have merge conflicts, maybe that's here.
There was a problem hiding this comment.
I have removed this entire section since.
| @@ -376,148 +303,114 @@ limitations we saw before `if constexpr` was introduced: Function templates | |||
| often had to rely on helper structs to do simple things. | |||
|
|
|||
|
|
|||
| ### Allowing unversal template parameters in code | |||
| ### Dependent Names | |||
|
|
|||
| To make this feature easier to use we also propose that universal template | |||
There was a problem hiding this comment.
This is from my recent PR so maybe there was a mistake with "late" above. Lets handle that later.
There was a problem hiding this comment.
Yeah, your recent PR handled things differently from what I'm proposing. This PR merges/rewrites our two PRs to use the "dependent names as template arguments are UTPs" rule. This means that the subsection "Deferring kind checking to instantiation" is outdated because UTPs/dependent names are promoted to UTPs when used as template arguments. There kind is a UTP in the parsing context. The UTP is narrowed to a type or value in other contexts but is the root kind here.
There was a problem hiding this comment.
It seems most of the changes that were in this PR are gone, so your comment here above is not valid, I think. As for the title none of them is actually good. I rather wish we had defined that we will use UTP throughout to avoid the recurring long "universal template parameter" everywhere. That would bring my title into reasonable length at least.
|
|
||
| With universal template parameters this problem will be more articulated, | ||
| especially when universal template parameters are forwarded directly as in: | ||
| This rule also applies when universal template parameters are not explicitly |
There was a problem hiding this comment.
This is almost the same as on row 315.
There was a problem hiding this comment.
Yes, Line 315 was a summary saying that this rule change affects UTPs and dependent names in general. This line goes into detail on the second half, extending "Down with typename!"
There was a problem hiding this comment.
And now that change is gone? Am I seeing the wrong diff?
| that `caller2` can't be instantiated with a type even though f has an overload | ||
| for types. | ||
| In C++20, `T::name` would be parsed as a value. However, according to this new | ||
| rule, `T::name` would become a universal template parameter, which would then |
There was a problem hiding this comment.
I don't think it becomes a universal template parameter, rather dependent names and universal template parameters work the same. Also I don't know if changing this example from a UTP based to a dependent name based is a good idea. It's very hard to get an overview in these diffs, unfortunately.
There was a problem hiding this comment.
Look at it in non-diff format. This is a rewrite of both our sections.
We need to show how it affects dependent names. I think it makes a lot of sense to treat these dependent names as promoted to UTPs, the "root" of all types/NTTPs/etc. that can then become narrowed in context.
|
Basically, this PR changes the way we look at things such that the parsing of dependent names and UTPs is completely unified. UTPs can be viewed exactly as dependent names and dependent names/UTPs operate as UTPs when passed as template arguments. |
|
Accept friend request :) i have done work on the r3 branch after i merged
everything to try and get examples first.
Let's reconvene on discord.
…On Sun, Sep 11, 2022, 19:31 camaclean ***@***.***> wrote:
Basically, this PR changes the way we look at things such that the parsing
of dependent names and UTPs is completely unified. UTPs can be viewed
exactly as dependent names and dependent names/UTPs operate as UTPs when
passed as template arguments.
—
Reply to this email directly, view it on GitHub
<#32 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA5R5PCPWXEHSCJMAAXKGDV5YQQ3ANCNFSM6AAAAAAQJ3QSWU>
.
You are receiving this because your review was requested.Message ID:
***@***.***
com>
|
| The dependent name rules shall be modified such that dependent names passed as | ||
| template arguments are promoted as universal template parameters. This allows | ||
| `using type = X<U>;` above to work as expected and slighlty extends "Down with | ||
| `typename`!". |
These sections had some overlap and I think the rules proposed regarding dependnet names in the "using universal templates in code" section overly complicated things. What I propose instead is to modify the dependnet name rules to promote dependnet names to universal template parameters in the narrow context of dependnet names used as template arguments (see text for detailed explanation). Because dependent names and UTPs are only visible as UTPs in this narrow context, there's no need for re-evaluation or anything like that.