Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

, Sep 8, 2020 at 9:25 PM Ian Lance Taylor wrote: > On Tue, Sep 8, 2020 at 5:47 PM Steven Blenkinsop > wrote: > > > > > > Reading over the pointer method example, I noticed that a derived type > cannot be inferred in a nested call while leaving method constraints intact:

Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

Reading over the pointer method example, I noticed that a derived type cannot be inferred in a nested call while leaving method constraints intact: type DerivedTypeConstraint[T any] interface { type *T Method() } func Foo[T any, PT DerivedTypeConstraint[T]](_ T) {} func Bar[T any, PT

Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

On Thu, Aug 13, 2020 at 7:35 PM, jimmy frasche wrote: > If I have > func F[type E interface{}, S constraints.Slice[E]]() S > are the following equivalent: > F[int, []int] > F[int] > F[[]int] > or are only 2 of the 3 permissible? Does that change if I swap the > type parameters? >From

Re: [go-nuts] [ generics ] Added constraint type inference to the design draft

On Thu, Aug 13, 2020 at 6:30 PM Ian Lance Taylor wrote: > > If I understand you correctly, we changed that when we added the > constraint type inference section. See the updated > > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference >

Re: [go-nuts] Generics and parentheses

On Wed, Jul 22, 2020 at 8:02 PM, Russ Cox wrote: > So it sounds like everyone is in favor of the entire generics proposal and > all the semantics, and all we have left to hammer out is the bracket > characters? Do I have that right? > > Best, > Russ > I think this thread is specifically about

Re: [go-nuts] Generics and parentheses

On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba wrote: > I'd say a dot is necessary when instantiating a function call but > unnecessary when instantiating a type because it's always syntactically > clear when a type is required. > That's not true in Go. Conversions look like function calls:

Re: [go-nuts] Re: [generics] Fuzzer, Type Switches

On Sun, Jul 19, 2020 at 11:43 AM, Jake Montgomery wrote: > This seems to work: https://go2goplay.golang.org/p/8veymwXYCoZ > > > I'm confused. It panics when I run it now. > Since the outcome is probably cached, I'm not sure how that could be the case. Did you mean to respond to Ian's modified

Re: [go-nuts] [generics] Fuzzer, Type Switches

> On Jul 18, 2020, at 9:00 PM, Ian Lance Taylor wrote: > > On Sat, Jul 18, 2020 at 3:43 PM wrote: >> >> This seems to work: https://go2goplay.golang.org/p/8veymwXYCoZ >> >> Still uses interfaces internally. > > Compare that to https://go2goplay.golang.org/p/8U4h9flkhFN. > > Ian Seems

Re: [go-nuts] [generics] Issues with identifying the matched predeclared type

sting code that is only written to support particular types for one reason or another. On Wed, Jul 8, 2020 at 3:59 AM roger peppe wrote: > > > On Wed, 8 Jul 2020 at 00:33, Steven Blenkinsop > wrote: > >> On Tue, Jul 7, 2020 at 10:44 AM, roger peppe wrote: >> >>&

Re: [go-nuts] [generics] Issues with identifying the matched predeclared type

ic(io.ReadCloser) above). >>> case U: >>> // Both type parameters are exactly the same type. >>> } >>> } >>> >>> >>> *Discussion* >>> >>> It might be a good idea to allow a type switch to specify a

Re: [go-nuts] [generics] Issues with identifying the matched predeclared type

On Mon, Jul 6, 2020 at 6:29 PM, roger peppe wrote: > > I've also been playing around in this area. I've been trying something > similar to this approach: https://go2goplay.golang.org/p/sHko_EMhJjA > But this isn't ideal - note that we lose type safety when assigning back > to the generic hash

Re: [go-nuts] [generic] Readibility of Multiple Parenthsis

On Sun, Jul 5, 2020 at 12:22 PM, Jake Montgomery wrote: > I understand Ian's position of wait and see. But for completeness, I will > point out that this new 'ambiguity' is different from the current cases > where there would be a "collision > between a variable name and a type name." As far as

Re: [go-nuts] [generics] Interface as a contract criticism

On Sat, Jul 4, 2020 at 5:50 PM wrote: > Both > > type X int | string > > and > > type X interface int, string > > Are meant to be a syntax sugar for: > > type X interface { > type int, string > } > > It is not a sum type, but rather a generic type that needs to be > instantiated before the use.

Re: [go-nuts] Generics: type-list vs method-based constraints -- not orthogonal?

On Fri, Jul 3, 2020 at 3:16 PM, Ian Lance Taylor wrote: > > The trick with this kind of approach is understanding what should > happen if the type with a package-specified method is converted to an > empty interface type, handed to some other package, and then in some > way handed back to the

Re: [go-nuts] [generics] use interfaces in type lists

On Fri, Jul 3, 2020 at 3:05 PM, Ian Lance Taylor wrote: > > Using an interface type in a type list has a defined meaning: the type > argument must have as its underlying type that interface type. It > doesn't mean what I think you want it to mean, which is to serve as a > union of the type

Re: [go-nuts] Generics: type-list vs method-based constraints -- not orthogonal?

Passing in two type parameters, one which is the type used by the caller and one which implements the interface, would almost work if conversions were allowed between type parameters with the same underlying types: https://go2goplay.golang.org/p/ylchcyACuV7 You have to double parameterize

Re: [go-nuts] Re: Contracts Draft: why are method pointers allowed

This text seems somewhat contradictory: The function Init cannot be instantiated with the type MyInt, as that type > does not have a method Set; only *MyInt has Set. > ... > If a method is listed in a contract with a plain T rather than *T, then it > may be either a pointer method or a value

Re: [go-nuts] Generics Draft: Mixing types and methods.

distinction between them. On Sat, Aug 3, 2019 at 2:11 AM, Ian Lance Taylor wrote: > On Fri, Aug 2, 2019 at 9:25 PM Steven Blenkinsop > wrote: > > > > On Fri, Aug 2, 2019 at 6:55 PM 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >

Re: [go-nuts] Generics Draft: Mixing types and methods.

On Fri, Aug 2, 2019 at 6:55 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > > contract Comparable(T) { > T comparable, Equal(T) bool > } > Wait, does this work? I mean, `comparable` is a contract, but it's being used as a constraint. Could you also write: contract

Re: [go-nuts] Re: Contracts Draft: why are method pointers allowed

On Thu, Aug 1, 2019 at 6:35 AM, Max wrote: > Thus it would require 'T' to be a pointer - namely '*big.Int' - to match. > It would mean that the receiver itself of the contract 'T Cmp(other T) > int' is a pointer. Is it a case allowed by contracts? > Yes, this is something which is supported be

Re: [go-nuts] Contracts Draft: why are method pointers allowed

On Mon, Jul 29, 2019 at 2:25 PM, Ian Lance Taylor wrote: > The motivation is to avoid requiring contracts to specify whether a method > is a pointer method or a value method, just as we do not require interface > types to specify whether a method is a pointer method or a value method. > I'm not

Re: [go-nuts] Allow methods on primitives

> > If one library defines string.Render() for html, and another defines > another string.Render() for, say, a graphics library, which Render will be > called when I call "str".Render()? Method call syntax is the least of the worries. Presumably, that could be based on which packages are

Re: [go-nuts] In-Method declaration of array of struct literals vs global var?

= is always required when you're assigning a value to the var. the confusion might be that you can also have a declaration like var bar []struct{a, b, c string} where you don't assign a value to bar (meaning it will be null). Really, the syntax is var variableName Type = value You can leave

Re: [go-nuts] Re: Generic types - functions and methods on instantions

On Tue, Sep 11, 2018 at 5:46 PM, Ian Lance Taylor wrote: > > While methods can be a convenient way to organize code, their only > real semantic meaning is to satisfy interfaces. They also represent a limited form of type-directed function overloading. A package can contain multiple methods

Re: [go-nuts] Link: Getting specific about generics

On Tuesday, September 4, 2018 at 6:07:32 PM UTC-4, xingtao zhao wrote: > > > > On Tuesday, September 4, 2018 at 2:26:58 PM UTC-7, Steven Blenkinsop wrote: >> >> If we try to translate contracts into interfaces, the first thing we run >> into is that there's no

Re: [go-nuts] Link: Getting specific about generics

If we try to translate contracts into interfaces, the first thing we run into is that there's no way to refer to the dynamic type of the interface. Compare: contract Fooer(t T) { interface{ Foo() T }(t) } to type Fooer interface { Foo() ??? } There would have to be some

Re: [go-nuts] Re: An issue with the select statement.

There's a reason Go doesn't support non-random selects. Often, you'll be selecting on channels which peers are accessing concurrently. In this situation, there's no ordering guarantee between when different cases will become available. If case 2 can become available ever-so-slightly before case 1,

Re: [go-nuts] Re: Go could really use a while statement

loop could be used as syntax for Roger Peppe's loop: loop if x = next(); x != nil { ... } I guess you could also call that for if, but that makes me think of for if me, ok := i().(OscarMayerWeiner); ok { for _, person := range everyone { love[person] = me } } On

Re: [go-nuts] Why does assigning a function variable to a method value allocate memory?

On Wed, Aug 23, 2017 at 6:20 AM Bakul Shah wrote: > This is a Mealy machine, where the next state > depends on the current state and current input (in s/w not > much use for a Moore machine unless you are driving/simulating > some regular physical process, in which case you

Re: [go-nuts] Re: Go 2 suggestion - Types like "int?"

Other places where Go relies on every type having a zero value: // Making slices with non-zero length. s := make([]*int, 10) // Reslicing a slice beyond its length. s := make([]*int, 0, 10)[:10] // Eliding fields from a composite literal. p := struct { x: int; y: *int }

Re: [go-nuts] Why does vet's 'rangeloop' check only check the last statement of a loop?

If you have a loop like: for i := range slice { f() } There's no way to know whether f launches a goroutine that captures the loop variable without also evaluating the body of f and potentially every function directly or indirectly called by f. If i escapes into a global variable, you also

Re: [go-nuts] Why is reflect.ValueOf(nil map).Interface() != nil?

Perhaps for clarity, the trip through reflect is a red herring. All you need is to put the map in an interface: package main > > import ( > "fmt" > ) > > func main() { > var m map[string]interface{} > if m != nil { > panic("m != nil") > } > var i interface{} = m > if i == nil { > // I expect