On Wed, Jul 22, 2020 at 5:12 PM Aleksey Tulinov
<[email protected]> 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.
Ian
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUoo42KdGYjOKRwZRtGtsYAdPE-GiLQyG-UGsbh8KwFcg%40mail.gmail.com.
