[generics] Why is constraint optional?

[Hal]

"If a constraint is specified for any type parameter, every type parameter must have a constraint. If some type parameters need a constraint and some do not, those that do not should have a constraint of interface{}."

"interface{}" equals to "Any Type" in the context of generics. So it seems that we don't have to support optional constraint, for the following reasons:

* the syntax defining generic function is verbose on purpose (type keyword), not only for clarification, but also a remind of the cost and complexity behind generics, so it is not a bad thing to be explicit about the the default constraint interface{}

* normal parameter list does not support default type, to be consistent, type parameter list should not either

* multiple generic types without constraints can be written as "type T1, T2, T3 interface{}", not too much boilerplate anyway

[Brian Candler]

Consider a generic where you want T1 unconstrained but T2 constrained.  If you write

func Foo(type T1, T2 Bar)

then Bar constrains both.  Hence the need for

func Foo(type T1 interface{}, T2 Bar)

[Hǎiliàng Wáng]

Hi Brian,

Thanks for your reply but I don’t think you get my point, what I mean is constraint should be always explicitly specified, so we should not support “optional” or “omitted” constraints.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/ztJvMz-FxbY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7df05c73-7c35-43e5-bdb4-44b6a73867cfo%40googlegroups.com.

--

Hǎiliàng

[Brian Candler]

Sorry, I understand what you're saying now.  I quite like "type T" meaning "any type", but you have a fair point.

[Axel Wagner]

On Wed, Jun 17, 2020 at 1:19 PM Hal <hwan...@gmail.com> wrote:

* the syntax defining generic function is verbose on purpose (type keyword), not only for clarification, but also a remind of the cost and complexity behind generics

I don't know where this idea is from, but it's not accurate. The type keyword is there to resolve a syntactical ambiguity: Without it, you couldn't tell if `func F(A) (B)` is a function taking an A and returning a B, or a generic function with type-parameter A and argument B.

The design draft actually opts to *not* be overly verbose, e.g. by omitting the `type` keyword and constraints in method receivers of generic types. 

* normal parameter list does not support default type, to be consistent, type parameter list should not either

I think it's fair to say that there is a semantical asymmetry here, in that while there is a natural choice for a default constraint (namely being unconstrained), there isn't one for parameter-types.

* multiple generic types without constraints can be written as "type T1, T2, T3 interface{}", not too much boilerplate anyway

I think in practice, something else would happen in many cases: Authors would want a shorter way to write this, so packages would start declaring `type Any interface{}` and use `Any` as a constraint - or use any of a dozen or so names for the concept.

This isn't a deal-breaker to me, either way. But I don't really see a good reason to forego this obvious small quality-of-life improvement. It's pretty clear what it means to have no constraint anyway.

 

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a1315d89-febe-4bac-9246-b463dc097af1o%40googlegroups.com.

[Ian Lance Taylor]

Our limited experience suggests that by far the common case is that
type parameters have no constraints. It seems annoying to force
everyone to write interface{} all the time when it is normally not
needed.

Ian

[eric fang]

It seems annoying to force
everyone to write interface{} all the time when it is normally not
needed.

I agree, omitting interface{} should not cause much trouble to the parser.

[Andrey Tcherepanov]

Wouldn't it be nice to have just

func Foo(type T1, type T2 Bar)

(type as keyword splitting it into 2 type declarations)

[Hal]

Yes, an alternative syntax I can come up with (underscore as a placeholder):

func Foo(type T1 _, T2 Bar)