On Sunday, August 9, 2020 at 4:17:06 AM UTC+12, Ian Lance Taylor wrote:
>
> On Fri, Aug 7, 2020 at 6:54 PM Robert Engels > wrote:
> >
> > I’d really like to see an example of generic code that takes both string
> and numeric types that uses operators. Sorting/searching is one but as I
> alre
On Wed, 12 Aug 2020 at 16:43, 李晓辉 wrote:
> Maybe `type list` equals to `sum type`
>
> type SignedInteger interface {
>type int, int8, int16, int32, int64
> }
>
> can replaced by
>
> type SignedInteger int|int8|int16|int32|int64
>
Yes, I've had that thought too (and mentioned it as feedba
Maybe `type list` equals to `sum type`
type SignedInteger interface {
type int, int8, int16, int32, int64
}
can replaced by
type SignedInteger int|int8|int16|int32|int64
func max[type I SignedInteger](a I, b I) I {
if a > b { return a }
return b
}
在2020年8月9日星期日 UTC+8 下午
On second thought, that would lead to ‘operator overloading’ and the abuses it
invites - so oh well - I guess we write duplicate methods based on types -
which is pretty much what you can do now - write a base implementation using
interface{} and then a small wrapper struct that types it. Given
Understood. Even if you keep operators they could be mapped to certain built in
interface methods. C++ has operator loading, Java does not (except for
auto-boxing) It seems Go generics are trying to play in the middle and I think
the end result is going to lead to confusing code, but we shall s
On Fri, Aug 7, 2020 at 6:54 PM Robert Engels wrote:
>
> I’d really like to see an example of generic code that takes both string and
> numeric types that uses operators. Sorting/searching is one but as I already
> said the built in string operators are not sufficient for collation cases.
>
> Eve
On Fri, Aug 7, 2020 at 7:54 PM Robert Engels wrote:
>
> I’d really like to see an example of generic code that takes both string and
> numeric types that uses operators. Sorting/searching is one but as I already
> said the built in string operators are not sufficient for collation cases.
>
> Eve
I’d really like to see an example of generic code that takes both string and
numeric types that uses operators. Sorting/searching is one but as I already
said the built in string operators are not sufficient for collation cases.
Even generic code that “only works on unsigned types”.
More than
On Thu, Aug 6, 2020 at 1:17 PM Ian Lance Taylor wrote:
>
> On Thu, Aug 6, 2020 at 12:10 PM Robert Engels wrote:
> >
> > We’ll probably agree to disagree there. Java has a lot of generic code
> > written and it’s never been a problem (using methods). Rarely can you write
> > code that treats + t
On Thu, Aug 6, 2020 at 12:11 PM Axel Wagner
wrote:
>
> On Thu, Aug 6, 2020 at 8:53 PM Ian Lance Taylor wrote:
>>
>> My point wasn't that a string is a number. My point was that the
>> current design draft permits writing a function that uses + and works
>> with both strings and numbers.
>
>
> Is
On Thu, Aug 6, 2020 at 12:10 PM Robert Engels wrote:
>
> We’ll probably agree to disagree there. Java has a lot of generic code
> written and it’s never been a problem (using methods). Rarely can you write
> code that treats + the same no matter if passed a string or numeric.
>
> Even operators
On Thu, Aug 6, 2020 at 8:53 PM Ian Lance Taylor wrote:
> My point wasn't that a string is a number. My point was that the
> current design draft permits writing a function that uses + and works
> with both strings and numbers.
Is there a need for that? I can't really imagine one.
That being s
We’ll probably agree to disagree there. Java has a lot of generic code written
and it’s never been a problem (using methods). Rarely can you write code that
treats + the same no matter if passed a string or numeric.
Even operators like < with strings don’t really make a lot of sense because
di
On Wed, Aug 5, 2020 at 8:52 PM Robert Engels wrote:
>
> I understand your point, but I think a few minor corrections Make a
> difference - it does not matter that String supports + and not - , a string
> would not be a Number. String concatenation is not addition.
My point wasn't that a string
I understand your point, but I think a few minor corrections Make a difference
- it does not matter that String supports + and not - , a string would not be a
Number. String concatenation is not addition.
There are also several ways to implement “ordering” with complex numbers, even
between co
On Wed, Aug 5, 2020 at 6:28 PM Robert Engels wrote:
>
> True, but cant Comparable be implemented by all built types? And Number be
> implemented by numeric types? Sure, you can’t use the operators in generic
> code but given most generic code is collections based it seems not a big loss.
The mo
True, but cant Comparable be implemented by all built types? And Number be
implemented by numeric types? Sure, you can’t use the operators in generic code
but given most generic code is collections based it seems not a big loss.
> On Aug 5, 2020, at 4:30 PM, Ian Lance Taylor wrote:
>
> On Tu
On Tue, Aug 4, 2020 at 9:19 PM Robert Engels wrote:
>
> The operator support is what makes things so complicated. Why not define a
> “numeric” type that has methods for all the operators that is used with
> generics, similar to Number in Java. Then it is unified. If you are writing
> specialize
The operator support is what makes things so complicated. Why not define a
“numeric” type that has methods for all the operators that is used with
generics, similar to Number in Java. Then it is unified. If you are writing
specialized math performant code you would probably use concrete types an
On Tue, Aug 4, 2020 at 7:31 PM Ben Hoyt wrote:
>
> > Yes, I think that the ability to write generics using operators is not
> > optional. As I've said before, there are some functions that must be
> > possible to write using any plausible generics mechanism. One of them
> > is the Min function t
> Yes, I think that the ability to write generics using operators is not
> optional. As I've said before, there are some functions that must be
> possible to write using any plausible generics mechanism. One of them
> is the Min function that returns the smaller of two values of some
> ordered ty
On Mon, Aug 3, 2020 at 5:10 PM 'Axel Wagner' via golang-nuts
wrote:
>
> IMO the discussion about this is purely based on the idea of type-lists which
> exists purely so as to support operators on type-parameters. And personally I
> feel a better way to solve this solution would be to just drop t
FWIW, the "generic types" alternative syntax proposal:
https://github.com/golang/go/issues/39669 includes an explicit distinction
between generic interfaces and regular interfaces, and an earlier iteration of
this idea included a new keyword, e.g., `prototype`, that would signal this
distinctio
Thanks for the thoughtful response.
> I'm still strongly in favor of not having it. In particular, there is a large
> section of conceptual overlap between interfaces and constrained
> type-parameters. And at least as far as function parameters go, an interface
> parameter can always be re-writ
On Tue, Aug 4, 2020 at 1:01 AM Ben Hoyt wrote:
> In terms of a "solution" for this, one that I'm sure has been thought
> about: what about keeping type constraints and interfaces completely
> separate? They are half the time anyway (when there are type lists),
> so why not make them separate all
Per Ian's suggestion on the other thread I started
(https://groups.google.com/g/golang-nuts/c/u9jqLPhEYO0/m/tnqezci8AwAJ),
I'm breaking out this topic into a separate thread:
It seems strange to me that interfaces with type lists are really a
different beast than regular interfaces, and aren't eve
26 matches
Mail list logo
