Quoting alanfo (2018-10-13 13:26:18)
> Suppose we turn this strategy on its head and instead allow types which
> wouldn't otherwise do so support the ordering operators provided they
> satisfy a simple interface. This interface would have a single method
> which returned a string representation of an object of that type and
> the compiler would use this string to implement the ordering operators.
> which would enable us to do this:
> p1 := Person{"Donald", 1, 20}� � // stringifies as Donald180
> p2 := Person{"Donald", 2, 72}� � // stringifies as Donald128
> b := p1 < p2� // false because p2 is older and therefore sorts first
..but you end up with `Person{"Donald", 3, 101}` < Person{"Donald", 2,
72}` being true, because the 101-year-old overflows the two digit space
you've allocated.
You can make this work by padding out to enough digits to be able to
represent any `uint`, but this example suggests to me that the approach
is likely to be error-prone in practice. My other immediate reaction is
the efficiency concerns, which you bring up yourself.
What is the advantage of the OrderString() approach over e.g. just
having `x < y` desugar to `x.Less(y)` (if a method `Less` is defined on
the type of x)? It is not clear to me what you suggest buys us over
this.
> I apologize if it's already been
> suggested by someone else but I'm losing track of what has been
> suggested in this area.
..it's probably getting to be time to add some organization to the wiki
feedback page.
--
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.
