On Wed, Jul 22, 2020 at 5:12 PM Aleksey Tulinov
<aleksey.tuli...@gmail.com> wrote:
> Hmm. I must have read the previous version, but it probably was some
> time ago. I have to say that i like the previous version more than the
> current one.
> I definitely don't like this:
> type structField interface {
>   type struct { a int; x int },
>     struct { b int; x float64 },
>     struct { c int; x uint64 }
> }
> If this is more readable than `require (a) { a.x++ }`, then i don't
> even know what to say. My understanding of readability must be very
> different.

Agreed.  But this is an extreme special case, only included in the
design draft as an example.  Personally I think it would be fine if
generics in Go had no way to say "the type must be a struct with a
numeric field x."

> However the real point is not in a syntax, but in decoupling require
> expression from constraint, so it's more generic and extensibleso to
> speak. So maybe:
> type IncrementX interface {
>   require (a) {
>     evaluates(a.x) && evaluates(a.x++)
>    // where evaluates() is defined elsewhere like `require (x) { x }`
>   }
> }
> And type requirement could be `require { type int, int8, int16, int32,
> int64 }`? Even though this still doesn't look right to me.

The more language constructs we add, the harder the language is to
understand.  The current design draft adds two language constructs:
type parameters and type lists in interfaces.  It adds one new name:
comparable.  Every new name, like "require" or "evaluates", carries a
heavy cost in comprehensibility, as it becomes something that every
user of Go needs to learn.

> >The objection you mention to the approach used in the current draft is 
> >something like: what if Go changes such that operators (other than == and 
> >!=) apply to types other than primitive types?  But we're in charge of Go;
> Yeah, sure. But there will be some code out there that depends on
> existing constraints. If I understand this correctly, `Ordered` in the
> current proposal does not define constraint that require operator `<`,
> it defines a specific set of types and exploits a side effect that
> operator '<' can be applied to every type from this set. This
> introduces other side effects, for example, operator `==` is also
> defined for all those types, so at least it defines what it wasn't
> supposed to define.
> I'm not sure if this is OK or not, just saying, but if Go somehow
> changes "interface" of types under `Ordered`, then I think `Ordered`
> will indirectly change its meaning because it will inherit those
> changes even if they are unrelated to operator `<` or ordering in
> general. Just wanted to point out that side effects work both ways,
> and if those side effects are already exploited in existing Go code,
> then it might be harder to change other parts that at first sight are
> completely unrelated to what is being changed. Hope this helps.

All true.  The question is whether it is likely to lead to problems.


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.
To view this discussion on the web visit 

Reply via email to