I don't know if fragmenting the conversation will improve or decrease clarify. I also agree that we should primarily focus on the existing generics design by Ian and Robert. So if you find this kind of conversation counter-productive, please ignore :) That being said, I also feel I'll understand the contracts design and the constraints leading to it better, if I actually talk through alternatives. So, I'll try and dedicate a thread to my alternative:
https://blog.merovius.de/2018/09/05/scrapping_contracts.html So far, there have been some things brought up about it that I found helpful to organize my thoughts: * Making pseudo-interfaces types may not be a good idea. In `func F(a, b comparable)`, a and b have the same type, but are not necessarily comparable with *each other* (as F(42, "foo") would be valid). Similarly, being interfaces, you could pass `nil` for them, which isn't great. So it's likely necessary to distinguish between constraint-specs and types. That is one function "contracts" in the original design serve which my approach currently fails at. I think it's a problem that can be fixed (in a hypothetical actually full design or proposal) while maintaining the core difference I see to the contract design: Using a more declarative and less ambiguous language to specify constraints. * My post intentionally splits type-parameters, constraints and operators-as-constraints into separate things, because I think it might be possible to implement generics as these separate steps, making each individual design lower risk and giving the chance to incorporate feedback into the later stages. The contracts design allows that too - at least splitting type-parameters and constraints. So we could consider doing that split there too. * My post does not talk about assignability and convertability. An actual design or proposal will have to make that explicit, but the idea would be to have `convertibleTo(T)`, `convertibaleFrom(T)`, `assignableTo(T)`, `assignableFrom(T)` pseudo-interfaces. That being said, specifically in regards to the assignability, I'm not sure it's needed (see next bullet point) and would be thankful for an example of a problem that requires it. * I think constraining type-parameters to channel/slice/map types might not be needed at all. Instead of, say "func Foo(type T channelOfBar) (ch T)", ISTM that we can use "func Foo(ch chan Bar)". Since any channel-type with element type Bar can be assigned to `chan Bar`, this would already allow most of the useful patterns. As-is there is a slight reduction in power over the contracts design, because `contract channelOfBar(v T) { ch <- Bar{} }` also allows element types that Bar is assignable to. `assignableFrom(Bar)` would enable pseudo-interfaces to do that too. But IMO it would be helpful to see cases where that's needed (AFAICT none of the ones mentioned in the design doc or problem overview do). * My post does not allow to constrain on struct fields. This is a fundamental reduction in power over contracts (type-parameters can't be identifiers, but only type names so can't solve this like assignability/convertibility). I don't understand the cases this is needed. The design doc mentions this at one point <https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#fields>. Personally, I find the example a bit contrived. The examples section <https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#examples>contains more realistic use-cases and I'd find it helpful to get something more in line with that to understand the need. In either case, this won't ever be possible with a {pseudo-,}interface based constraint spec, so would require going through boiler-plate accessor methods (like it does currently with interfaces). I CC'ed Larry, as he mentioned that he needs field-accessors. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
