Passing generic arguments to template parameters #136

josh11b · 2020-08-04T04:24:33Z

No description provided.

fowles · 2020-08-04T05:09:17Z

docs/design/generics/generic-to-template.md

+Note that these options are somewhat independent. We could adopt none of these,
+or a combination of multiple options.
+
+### Adopting none of the below options


I would label this heading "Option 0: Forbid Calling Templates from Generics" as that really does describe this better than the phrase "don't do any of the below"

I renamed the section, though I rephrased.

fowles · 2020-08-04T05:10:34Z

docs/design/generics/generic-to-template.md

+    accepting `std::optional`, `std::unique_ptr`, and the like.
+
+As a consequence, we also consider more complex options where the usage is
+allowed.


This also make evolution harder. You cannot change a generic to a template without breaking all callers that are generic

Added some text to try and capture this concern.

fowles · 2020-08-04T05:16:59Z

docs/design/generics/generic-to-template.md

+One concern with this approach is if we want to use a dynamic strategy for
+compiling generics that only generates one copy of the function. In this case,
+the dynamic type test will be left in the code at runtime, with the associated
+runtime costs.


This could also be annoying as it a generic could refuse to compile because there exists a specialization that you the author know will never be needed

Yes, although in that case, shouldn't the generic explicitly declare T != Bool as one of its constraints anyway? Otherwise the generic doesn't fulfill its own contract -- it says it works for any type T, but it actually only works for types other than Bool.

If you want compile-time duck typing, where you don't have to declare those constraints, I think that means you should be using a template instead.

I agree with mconst here, this is a necessary constraint to fulfill the generic contract.

But then someone can add a template specialization to their template and break a generic at an arbitrary distance away

It is already the case that a change to a template, but particularly adding an overload with a different signature, can break callers of that template. It is true, though, that generic callers are a bit more fragile in this respect, since they can break because of cases that are not exercised in practice. I don't see an alternative other than option 2.

Yeah. This does seem like a good argument against option 3A, because in that case even adding a template specialization that doesn't change the interface at all would become a breaking change!

I've added some text under "Recommendation: defer option 3" below that hopefully captures this concern.

mconst

Thanks for writing this up! It looks good to me overall, and I think I agree with your evaluation of the three options.

mconst · 2020-08-04T10:00:13Z

docs/design/generics/generic-to-template.md

+-   Cannot use templates even when the desired behavior would easily be achieved
+    without using any part of the actual type parameters to the generic. The
+    classic example here is using templates with pointers to generic type
+    parameters that would work equally well with opaque pointers or `void`
+    pointers. The specific value of the generic type parameter in this case is
+    immaterial, but still blocks the usage because it is technically possible
+    for the template to use it in some way -- even if it happens not to in most
+    cases.


How important is this use case? In C++, templates like this are very common, but that's because C++ doesn't have generics. In Carbon, I was assuming this sort of code would normally be written with generics instead, so the issue wouldn't come up.

In fact, if we end up with a lot of templates like this in Carbon (where the actual type parameter isn't important most of the time, but it still can't be expressed as a generic for some reason), that kind of feels like a sign that the generics system isn't fulfilling its goals.

A few points:

We are starting from a large installed base of C++ code using templates that we are going to have to interop with to succeed. So this is important at the start before we can migrate code that can be generic to generics.

Part of what it is being discussed here is that even when you have a template that does something special for some types, it will usually treat all pointer types the same.

We don't know how big a concern this is, having both generics and templates is pretty new ground and, while I hope we can eventually migrate to mainly generic code, this depends a lot on how our users want to use Carbon.

This is some text I had copied from another doc without reviewing carefully. Are there some changes that would help clarify?

Right, I certainly agree that interop with existing C++ templates is important. It feels like that's already covered by the second use case, though (lines 113-116).

For native Carbon templates, it's still not clear to me that we want to worry about this issue at all. The sort of examples you're talking about, where all pointer types are treated the same, seem like exactly the sort of things that ought to be handled with generics in Carbon code -- and if for some reason generics aren't sufficient, it feels like we should start by improving the generics system to handle those cases, rather than adding workarounds that make it easier to use templates instead. It's true that we can't know how people will end up using generics and templates, but that also means it's kind of premature to worry about usability features for use cases we don't even understand yet.

So it kind of feels like we could delete this bullet point entirely. Our motivation for the feature would just be improving interop with existing C++ templates, which is a nice clear goal with well-understood use cases.

Alternatively, if there are native Carbon use cases that are also important here, it would be nice to see some examples of those.

The point I was trying to make was that all the pointer types may be treated the same by a template even when other types are not.

Hmm, it occurs to me that some of these issues come up even with overloads that don't involve templates.

@chandlerc You were the source of this text originally, would you like to chime in here?

In C++, templates like this are very common

I'm actually struggling to think of an example of such template. Most templates will use the type one way or another, even if it is to only know its size, or perform overload resolution.

mconst · 2020-08-04T10:01:34Z

docs/design/generics/generic-to-template.md

+One concern with this approach is if we want to use a dynamic strategy for
+compiling generics that only generates one copy of the function. In this case,
+the dynamic type test will be left in the code at runtime, with the associated
+runtime costs.


Yes, although in that case, shouldn't the generic explicitly declare T != Bool as one of its constraints anyway? Otherwise the generic doesn't fulfill its own contract -- it says it works for any type T, but it actually only works for types other than Bool.

If you want compile-time duck typing, where you don't have to declare those constraints, I think that means you should be using a template instead.

mconst · 2020-08-04T10:03:31Z

docs/design/generics/generic-to-template.md

+One concern with this approach is if we want to use a dynamic strategy for
+compiling generics that only generates one copy of the function. In this case,
+the dynamic type test will be left in the code at runtime, with the associated
+runtime costs.


This approach also seems likely to cause slow compile times, which is one of the things we're trying to get away from with generics.

Updated text to include this concern. I don't feel like I'm in a very good position to evaluate that concern myself, hopefully someone else can chime in.

mconst · 2020-08-04T10:16:39Z

docs/design/generics/generic-to-template.md

+-   Requires writing modular descriptions of templates’ interfaces, potentially
+    duplicating a large portion of an API already described in the template.
+-   Requires instantiating transitive closure of templates at the root of any
+    used generic.


These are just the instantiations that would happen if the generic were a template, right? That seems like a pretty natural consequence of calling a template.

I will update the text to make this concern a bit clearer:

Unlike for a template, this affects the signature of the generic -- it needs to mention any templates used. I give an example of that in the next section.

It is transitive through generic calls in addition to templates.

gribozavr · 2020-08-10T09:01:40Z

docs/design/generics/generic-to-template.md

@@ -0,0 +1,550 @@
+# Passing generic arguments to template parameters


I feel like this title uses the words "arguments" and "parameters" backwards. Based on the problem description, I'd describe it like this:

"Passing expressions that depend on generic parameters as template arguments"

I realize it is a bit nitpicky, but it is important to be precise because generics discussions are often quite subtle.

A filename suggestion: "generic-uses-template.md".

I was careful to be precise and I believe it is correct as is.

The problem is when you have a generic value for whatever reason (possibly but not necessarily because it depends on a generic parameter) that is used as an argument to a function that declares, in the position that argument is passed, that the parameter is a template.

gribozavr · 2020-08-10T09:03:40Z

docs/design/generics/generic-to-template.md

+the type is a generic value, is parameterized by a value only known generically,
+or as in the above example it could be a pointer-to-generic type. When `pointer`
+is passed to `TemplateFunction`, we need to assign some type to
+`TemplateParameter`.


Suggested change

`TemplateParameter`.

`TemplateParameter` in order to instantiate and type check the function template.

I'm using Chandler's suggested terminology where there are no "function templates", just parameterized functions where the parameters may be template or generic.

I agree the terminology is awkward, I've started a discussion in #typesystem.

docs/design/generics/generic-to-template.md

gribozavr · 2020-08-10T13:16:51Z

docs/design/generics/generic-to-template.md

+-   Does not require any deferred work when compiling users of the generic, all
+    type checking and code generation can be done in advance, as with all other
+    generic code.
+-   Does not require writing a modular description of templates’ interfaces.


Why doesn't it require writing such descriptions? In the example, isn't SomeInterface such a modular description of requirements?

The only case where we don't need to write a description is when the template places no restrictions -- effectively, not using the type in any way (even for overload resolution).

SomeInterface is a description of the capabilities of the value we are passing to the template, not a description of the requirements of the template. This one thing could be reused for calls to multiple templates. In general this reflects a difference between options 1 and 2 -- option 2 needs work per template called in both function signatures and wrapper interfaces/impls.

docs/design/generics/generic-to-template.md

gribozavr · 2020-08-10T14:14:11Z

docs/design/generics/generic-to-template.md

+    such as `std::optional` or `std::variant` reusing bits.
+-   May be a difficult model to teach as it affirms a distinction between the
+    type within the generic and the type argument to the generic.
+-   Does not enable use of C++ vocabulary types which are templates with generic


I wouldn't say that this option "does not enable" this use case. It enables this use case, but in a limited way -- the template instantiated on an archetype should better not escape the scope within which the archetype is defined, otherwise weirdness happens.

gribozavr · 2020-08-10T14:53:39Z

docs/design/generics/generic-to-template.md

+}
+```
+
+This would likely introduce some performance penalty (assuming it wouldn't all


The performance penalty should be comparable to a compiler-based implementation.

gribozavr · 2020-08-10T14:55:54Z

docs/design/generics/generic-to-template.md

+
+```
+// Assume `SomeInterface` has functions `F` and `G`.
+struct Archetype {


One way this implementation is different from the compiler-assisted one is how the archetype is typechecked.

In a compiler-assisted implementation, the archetype is based on the generic parameter. Therefore, we know that two objects that have archetype as their static type are wrapping two objects of the same exact actual type. That enables one to safely unwrap two archetype objects and pass the unwrapped objects to an operation that requires identical types on both sides, for example, ==.

In a manual implementation, we can't assume this. Two instances of struct Archetype can wrap objects of different types.

Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>

josh11b · 2021-02-02T23:02:48Z

docs/design/generics/generic-to-template.md

+-   Requires instantiating the transitive closure of templates at the root of
+    any used generic. This affects the signature of the function parameterized
+    by the generic, and transitively the signatures of any generic callers.
+


@dabrahams described to me a variant of this approach which makes a different trade off. In this variant, a statement by the user that "this template type conforms to this generic interface" is assumed to be true at type checking time for all types that satisfy the statement's constraints. This removes the second "con" -- there is no requirement to pass in a witness to the generic. It introduces another con in its place: we might get an error when we do instantiation/monomorphisation if the compiler discovers that for that particular parameter the template does not satisfy the generic interface. You will get this error even if it is due to some requirement of the interface that is not relied upon in the generic function.

This variant is described by dabrahams in this thread https://forums.swift.org/t/c-function-template-specialization-and-generic-functions-in-swift/42016/32 and was being considered as part of the C++/Swift interop investigation.

github-actions · 2021-08-01T01:52:32Z

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active, please comment or remove the inactive label.
This PR is labeled inactive because the last activity was over 90 days ago. This PR will be closed and archived after 14 additional days without activity.

github-actions · 2021-08-16T01:48:21Z

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active or becomes active again, please reopen it.
This PR was closed and archived because there has been no new activity in the 14 days since the inactive label was added.

Creating new proposal: Passing generic arguments to template parameters

9c37faf

josh11b added WIP proposal A proposal labels Aug 4, 2020

Filling out template with PR 136

fe40409

googlebot added the cla: yes PR meets CLA requirements according to bot. label Aug 4, 2020

josh11b added 2 commits August 3, 2020 21:52

First draft of 'Passing generic arguments to template parameters'.

b9c7a97

Fix section headings.

0358269

fowles reviewed Aug 4, 2020

View reviewed changes

mconst reviewed Aug 4, 2020

View reviewed changes

josh11b added 2 commits August 4, 2020 12:35

Incorporate initial feedback.

6a8fbba

Add text in response to review feedback.

09c0ba6

gribozavr reviewed Aug 10, 2020

View reviewed changes

josh11b and others added 6 commits August 11, 2020 11:13

Accept suggestion

61a3f08

Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>

Accept suggestion

43f50d1

Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>

Accept suggestion

f34dedd

Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>

Accept suggestion

fae3131

Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>

Accept suggestion

6405a7f

Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>

Remove TOC from proposal.

128ba51

josh11b commented Feb 2, 2021

View reviewed changes

jonmeow marked this pull request as draft April 20, 2021 16:19

jonmeow removed the WIP label Apr 20, 2021

github-actions bot added the inactive Issues and PRs which have been inactive for at least 90 days. label Aug 1, 2021

github-actions bot closed this Aug 16, 2021

github-actions bot added the proposal deferred Decision made, proposal deferred label Jul 25, 2022

josh11b mentioned this pull request Sep 7, 2022

Checked generics calling templates #2153

Closed

		@@ -0,0 +1,550 @@
		# Passing generic arguments to template parameters

	`TemplateParameter`.
	`TemplateParameter` in order to instantiate and type check the function template.

Passing generic arguments to template parameters #136

Passing generic arguments to template parameters #136

Conversation

josh11b commented Aug 4, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mconst Aug 5, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mconst left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Aug 1, 2021

github-actions bot commented Aug 16, 2021

mconst Aug 5, 2020 •

edited

Loading