On Wed, Jan 20, 2021 at 3:24 AM Brian Candler wrote:
>
> Yes. Conceptually at least, interfaces defined as type lists could be used
> as interfaces:
>
> type Foo interface { type int32, int64 }
> func f(a, b Foo) {
> if (a < b) ...
> }
>
> Without specialisation, there would be dynamic disp
On Wed, Jan 20, 2021 at 2:08 AM Brian Candler wrote:
>
> In the Generics proposal, type constraints (other than type lists) take the
> form of interfaces. For example, a generic type T may be constrained with
> interface C.
>
> Question: if a function takes type T, does that permit *both* value
On Wed, 20 Jan 2021 at 11:04, Brian Candler wrote:
> What do you make of this?
> https://go2goplay.golang.org/p/gN-FK2kbYK5
>
> Using interface values, it seems possible to bypass a declared constraint
> that two arguments have the same type.
>
This code is misleading. By passing the value to `r
On Wed, Jan 20, 2021 at 1:10 PM Brian Candler wrote:
> On Wednesday, 20 January 2021 at 11:53:23 UTC axel.wa...@googlemail.com
> wrote:
>
>> Can you come up with a realistic reason to have that constraint that
>> doesn't end up needing reflect anyway (where you can implement any checks
>> you wan
On Wednesday, 20 January 2021 at 11:53:23 UTC axel.wa...@googlemail.com
wrote:
> Can you come up with a realistic reason to have that constraint that
> doesn't end up needing reflect anyway (where you can implement any checks
> you want)?
>
Mainly it's programmer comfort. If I write a contain
On Wed, Jan 20, 2021 at 12:04 PM Brian Candler wrote:
> What do you make of this?
> https://go2goplay.golang.org/p/gN-FK2kbYK5
>
> Using interface values, it seems possible to bypass a declared constraint
> that two arguments have the same type.
>
I understand if people are confused by it. I fin
On Wednesday, 20 January 2021 at 10:53:10 UTC axel.wa...@googlemail.com
wrote:
> On Wed, Jan 20, 2021 at 11:08 AM Brian Candler wrote:
>
>> What I mean is, the difference between
>> func f(a, b fmt.Stringer) c fmt.Stringer { ... }
>> and
>> func f[T fmt.Stringer](a, b T) c T { ... }
>> would sim
On 1/20/21 10:42 AM, 'Axel Wagner' via golang-nuts wrote:
> IMO it is confusing to allow comparing generic values to nil, in general. If
> we
> could, I would either assume I can compare any *non*-generic value to nil. I
> would assume we can always go from a generic function to an instantiated on
What do you make of this?
https://go2goplay.golang.org/p/gN-FK2kbYK5
Using interface values, it seems possible to bypass a declared constraint
that two arguments have the same type.
I am wondering the following.
1. If the function signature says two types should be the same (via type
parameter
On Wed, Jan 20, 2021 at 11:08 AM Brian Candler wrote:
> With my wild hat on: it makes me wonder what would happen if the generics
> proposal became nothing more than interfaces with linked constraints - so
> that you could say "this function takes a function of type T (interface C)
> and returns
On Wed, Jan 20, 2021 at 11:08 AM Brian Candler wrote:
> The end result is there's a crucial but subtle difference between:
>
> type Foo interface { ... }
> func f(v Foo) ...
>
> and
>
> type Foo interface { ... }
> func f[T Foo](v T) ...
>
> Given that the second case supports both concrete types
On Wednesday, 20 January 2021 at 03:06:43 UTC bbse...@gmail.com wrote:
> Is it possible to write a generic function that can test if its
> argument with a constraint is nil?
>
I think there is a deeper question in there.
In the Generics proposal, type constraints (other than type lists) take t
12 matches
Mail list logo
