Does the return of a template function have template phase?

[josh11b]

Summary of issue:

#2153 does not address whether the return type of a template function has template phase

Details:

Interesting examples:

fn TemplateIdentity[template T:! type](x: T) -> T { return x; } 
fn Caller[T:! I](x: T) {
  // Does the type of `y` have template phase or is its type precisely `T`?
  let y: auto = TemplateIdentity(x);
}

// Do we want a generic caller to need a constraint that ensures `T.U` is defined to call this function?
fn TemplateNonIdentity[template T:! type](x: T) -> T.U { return x.F(); } 

[chandlerc]

My initial idea here is that the answer should be "no", but maybe even more than suggested above: maybe it should be an error to declare a function with a return type that is dependent on a template parameter?

And to make the examples work above, the declaration would have to explicitly make its return type itself a template -- I could imagine many syntaxes here, for example fn TemplateIdentity(template T:! type](x: T) -> template T { return x; }. But probably others as well.

The advantage I could see here is avoiding surprising or subtle dependence on a template, especially in functions that use a mixture of checked and template parameters and intend to have the return type only involve the checked ones.

But maybe there are disadvantages here that I'm not seeing that make it important to do this automatically?

---

Either way, once the return type is a template (implicitly or explicitly), I would propagate that to the type of the call expression but not to something like auto.

To try to illustrate with examples:

// However we want to write a function that *definitely* has a template return type.
fn TemplateIdentity[template T:! type](x: T) -> template T { return x; }

// Possible type...
class C {
  var x: i32;
}

fn GenericCaller[T:! type](v: T) {
  // Because we can call templates from a generic, this is allowed in the definition
  // but will require instantiation that may fail.
  let y1: i32 = TemplateIdentity(v).x;

  // This is allowed...
  let tmp: auto = TemplateIdentity(v);

  // But this is not...
  let y2: i32 = tmp.x;

  // Both of these are fine...
  let template ttmp: auto = TemplateIdentity(v);
  let y3: i32 = ttmp.x;
}

var c: C;
GenericCaller(c);

[josh11b]

An alternative to consider: the type of the return value has the same phase as the return type expression. So if it is dependent on a template parameter, it has template phase. Motivation for this approach includes (a) it is a simple rule consistent with our rules for template phase elsewhere in the language, (b) it allows constructs that require template phase, and (c) if the caller doesn't want a template phase value, the caller can then convert to symbolic phase using a let binding. Note though that the "just returning T" case might be expected to match the caller's phase by users, so this might be surprising behavior.

[chandlerc]

An alternative to consider: the type of the return value has the same phase as the return type expression. So if it is dependent on a template parameter, it has template phase. Motivation for this approach includes (a) it is a simple rule consistent with our rules for template phase elsewhere in the language, (b) it allows constructs that require template phase, and (c) if the caller doesn't want a template phase value, the caller can then convert to symbolic phase using a let binding. Note though that the "just returning T" case might be expected to match the caller's phase by users, so this might be surprising behavior.

It makes sense, but I think I still lean towards requiring the signature of the function to explicitly opt into it's return type having template phase. Inferring that from how the return is written in the body seems relatively brittle to me. In my comment, I gave the example of an author that didn't intend for a template phase expression to end up in the return and it doing so accidentally -- it seems like that would be an issue here.

[josh11b]

It makes sense, but I think I still lean towards requiring the signature of the function to explicitly opt into it's return type having template phase. Inferring that from how the return is written in the body seems relatively brittle to me. In my comment, I gave the example of an author that didn't intend for a template phase expression to end up in the return and it doing so accidentally -- it seems like that would be an issue here.

I meant that it would be determined by the return type expression (after the -> in the signature), not the return expression (after return in the body of the function).