Generics details 6: remove facets

[josh11b]

There were some concerns about facet types leaking out of generic code in return types. Some initial fixes for this were done in PR #900, but there remain concerns, for example when associated types are involved.

In particular, given an interface method with return type using an associated type, as in:

interface Deref {
  let Result:! Type;
  fn DoDeref[me: Self]() -> Result;
}

class IntHandle {
  impl as Deref {
    let Result:! Type = i32;
    fn DoDeref[me: Self]() -> Result { ... }
  }
}

Since Result has type Type, we had the problem that IntHandle.DoDeref would have to return i32 as Type, instead of the desired i32.

We also think we can simplify the model by eliminating the facet type concept and syntax.

This proposal removes facet types, introduces archetypes in their place, clarifies how associated types work outside of a generic function, and specifies how a generic let statement in a function body works.

[wolffg]

Some minor fixes.

[wolffg]

"straightforward" is a little evalulative. I think you could just say "should not affect..."

[josh11b]

I've changed it, but I would think "straightforward" was more okay as a goal than as a description of a design.

[wolffg]

I realize someone just clipped out a comma here, but this whole sentence makes me wonder: Are these two bullet points? Is this either/or? That is, interfaces can exist on their own. They can extend other interfaces. Also, separately, interfaces can require that interfaces inside them be implemented.

Put another way, why are these two things in the same bullet?

[josh11b]

Extending is requiring plus some extra stuff. I've made it two bullets, but it isn't obviously better to me.

[wolffg]

The way it was written before made it seem like you could one or the other; the new way makes it clear both are allowed.

[josh11b]

The way you write the code, you either require an interface or extend an interface, but it happens that extending an interface implies that you require it.

[zygoloid]

What does the template mean here?

[josh11b]

This proposal defines generic let, but it wasn't clear to me that generic let would allow you to give a name to a constraint without erasing something important. Template let clearly should work here, though, and I didn't see a downside to using a template in this context, other than not having written the template doc yet.

How should I proceed from here? For now my intent was simply to say "you can write let template to give a name to a constraint expression as can be seen in these examples"

[zygoloid]

As it stands, I think this proposal is introducing new let template syntax that didn't exist in the design before. If we want to add that let template syntax in addition to let syntax, I'd like to be clear on what the difference between the two is, semantically, and why we want to have both. My inference from the appearance of template here is that lets won't be fully referentially transparent, in particular for certain kinds of compile-time evaluation -- that there will be cases in which factoring out a constant into a named (non-template) let will change the meaning of the program in some ways -- but I'm not sure in which ways, or why.

There may be good reasons we want to distinguish between a non-referentially-transparent let and a referentially-transparent let template, but -- absent a rationale for why this is a consequence of removing facet types -- I think that should be a separate discussion. I'd suggest we revert all the let -> let template changes in this proposal and consider the let template change separately.

[josh11b]

One of the conclusions of the talk with @chandlerc was that let here with auto probably should be referentially-transparent, so I've replaced let template with let.

[zygoloid]

Thanks, this looks good to me, modulo the let template piece that I think we should consider separately.

[zygoloid]

Do we need the as Comparable here? This seems a bit facet-type-y.

[josh11b]

You are correct I missed making this change.

[zygoloid]

As it stands, I think this proposal is introducing new let template syntax that didn't exist in the design before. If we want to add that let template syntax in addition to let syntax, I'd like to be clear on what the difference between the two is, semantically, and why we want to have both. My inference from the appearance of template here is that lets won't be fully referentially transparent, in particular for certain kinds of compile-time evaluation -- that there will be cases in which factoring out a constant into a named (non-template) let will change the meaning of the program in some ways -- but I'm not sure in which ways, or why.

There may be good reasons we want to distinguish between a non-referentially-transparent let and a referentially-transparent let template, but -- absent a rationale for why this is a consequence of removing facet types -- I think that should be a separate discussion. I'd suggest we revert all the let -> let template changes in this proposal and consider the let template change separately.

[chandlerc]

FWIW, this LGTM as well. The whole generic let vs template let and related sty seems not super essential to this proposal. Mostly don't think it's worth slowing down, we can keep iterating there, either adding stuff if/when well motivated and understood or fixing it, either way.

Had an interesting chat with Josh about generic let's and more generally let's in impls, but again, I still think this is a good incremental step.