Re: [go-nuts] [generics] some questions

On Thu, Jun 18, 2020, 11:28 T L wrote: > How to declare a generic functions which converting a slice with type Ta > to a slice with type Tb. Like > func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...} > > How to constraint a type parameter must be of an interface type? > I don't think

Re: [go-nuts] Re: [generics] some questions

Hello, > But the following code also fails to compile, bug? > > package main > > type Int interface { > type int > } > > func Foo(type T Int) ([]T) {} // undefined: MyInt > > func main() { > type MyInt int > Foo([]MyInt(nil)) > } It compiles if you move "type MyInt int" out of the

[go-nuts] [generics] some questions

How to declare a generic functions which converting a slice with type Ta to a slice with type Tb. Like func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...} How to constraint a type parameter must be of an interface type? Is it possible to define generic unnamed types? If it is

[go-nuts] Re: [generics] Replace () with <> or other character

On Thursday, 18 June 2020 10:15:16 UTC+2, Nathanael Curin wrote: > > An argument for this is also that (all ?) languages that use generics use > <>. It might make learning just easier for new Go developers that have > experience from generics-compatible languages. > And an argument against

[go-nuts] Re: [generics] some questions

It looks the generic type argument must share the underlying type of a type in the constraint type list. But the following code also fails to compile, bug? package main type Int interface { type int } func Foo(type T Int) ([]T) {} // undefined: MyInt func main() { type MyInt int

Re: [go-nuts] [generics] some questions

On Thu, Jun 18, 2020, 13:21 T L wrote: > > > On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote: >> >> >> >> On Thu, Jun 18, 2020, 11:28 T L wrote: >> >>> How to declare a generic functions which converting a slice with type Ta >>> to a slice with type Tb. Like >>> func

[go-nuts] Re: [generics] some questions

Another question, how to make the following code compile: package main type IntSlice interface { type []int } func Foo(type T IntSlice) (T) {} func main() { type MyInt int Foo([]int(nil)) Foo([]MyInt(nil)) // []MyInt does not satisfy IntSlice ([]MyInt not found in []int) } --

[go-nuts] Re: [generics] some questions

It looks, in most cases, the current rules recommends the types shown in the constraint definition must be the elementary types. On Thursday, June 18, 2020 at 7:45:52 AM UTC-4, T L wrote: > It looks the generic type argument must share the underlying type of a > type in the constraint type

Re: [go-nuts] [generics] some questions

On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote: > > > > On Thu, Jun 18, 2020, 11:28 T L > wrote: > >> How to declare a generic functions which converting a slice with type Ta >> to a slice with type Tb. Like >> func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...}

[go-nuts] Re: [generics] replace ()/(type ) with :[]

Poll https://www.surveylegend.com/s/2dwe -- 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. To view this discussion on

Re: [go-nuts] Re: [generics] some questions

So, it is really a bug. I will report it. On Thursday, June 18, 2020 at 8:17:22 AM UTC-4, Harald Weidner wrote: > > Hello, > > > But the following code also fails to compile, bug? > > > > package main > > > > type Int interface { > > type int > > } > > > > func Foo(type T Int) ([]T)

[go-nuts] Re: [generics] replace ()/(type ) with :[]

> that quite hard to read especially at lines 7-12 '__') It might just be me, but I don't feel anything special... Go does not have any other syntax (e.g., macros) that let you use parentheses in type definition unless followed immediately by a `func`, and those parentheses can not be nested.

Re: [go-nuts] [generics] some questions

On Thursday, June 18, 2020 at 8:01:22 AM UTC-4, Axel Wagner wrote: > > > > On Thu, Jun 18, 2020, 13:21 T L > wrote: > >> >> >> On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote: >>> >>> >>> >>> On Thu, Jun 18, 2020, 11:28 T L wrote: >>> How to declare a generic functions

Re: [go-nuts] [generics] the empty type list

It is a type which cannot be inhabited by a term. These exist and often have uses. As Bryan wrote they also completes the type lattice, so rejecting them is often a lot of work for little gain. If you want examples, look up phantom types, where an uninhabited type is used as a tag for ensuring

Re: [go-nuts] [generics] is generics with constrain needed ?

Thanks, that is a great explanation :) On Thu, Jun 18, 2020, 03:49 Axel Wagner wrote: > I'd also say that converting between []Foo and []Stringer isn't actually > definable in a type-safe manner: > https://blog.merovius.de/2018/06/03/why-doesnt-go-have-variance-in.html > Slices are writable as

[go-nuts] Re: [generics] replace ()/(type ) with :[]

I don't know how many of us are here, but I for one, really feels comfortable and familiar with use of parentheses. I think anyone that is familiar with closures and functional programming would see it fitting, as if the generic function is a function that takes some type parameters and

Re: [go-nuts] [generics] the empty type list

An empty intersection of type lists cannot be instantiated with any actual type, but if type-list interfaces could eventually be used as run-time types (as suggested in https://golang.org/design/go2draft-type-parameters#type-lists-in-interface-types), then the interface with an empty

Re: [go-nuts] [generics] some questions

On Thursday, June 18, 2020 at 8:01:22 AM UTC-4, Axel Wagner wrote: > > > > On Thu, Jun 18, 2020, 13:21 T L > wrote: > >> >> >> On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote: >>> >>> >>> >>> On Thu, Jun 18, 2020, 11:28 T L wrote: >>> How to declare a generic functions

[go-nuts] [generics] replace ()/(type ) with :[]

Personally () parentheses seems like to be harder to read, too similar with function calls. It would be nicer if we use brackets instead [] like in Nim, since [] only used in array/slice/indexing (index key or empty), which is more readable than () that used in many ways (receiver,

Re: [go-nuts] [generics] some questions

On Thursday, June 18, 2020 at 7:20:38 AM UTC-4 tapi...@gmail.com wrote: > On Thursday, June 18, 2020 at 5:53:28 AM UTC-4, Axel Wagner wrote: >> >> On Thu, Jun 18, 2020, 11:28 T L wrote: >> >>> How to declare a generic functions which converting a slice with type Ta >>> to a slice with type Tb.

[go-nuts] Re: [generics] Closure?

I think this is a bug in the parser, related to (but not the same as) https://golang.org/design/go2draft-type-parameters#instantiating-types-in-type-literals . Adding doubled parentheses seems to make it work (https://go2goplay.golang.org/p/JSQ_8kGOC_A), but the `Format` button doesn't

[go-nuts] [generics] function type declarations pushes parameters too far right

Just a quick IMHO, The current proposal, where there is a type declaration between the function name and the function arguments, pushes the function arguments too far right. The function arguments, arguably, are more important (usually) than the specifics of the types required. Is there an

[go-nuts] [generics] Zero value

First, congratulations on the working compiler! Very cool to try out generics in Go. I was experimenting with some simple generic functions and felt the need for the zero value of a generic type. I've read the discussion anticipated in your proposal

Re: [go-nuts] [generics] replace ()/(type ) with :[]

" These are parameters, and should be thought of just like other parameters in a function call. .." parameters yes, but not in the current go context of 'parameter' .. Is it not better syntax for 'generic parameters' to use special, distinctive symbols e.g. C++ does via < Type > ?? On

Re: [go-nuts] [generics] Replace () with <> or other character

On Wednesday, June 17, 2020 at 5:50:24 PM UTC-7, Ian Lance Taylor wrote: > > On Wed, Jun 17, 2020 at 9:36 AM Charles Crete > wrote: > > > > Based on the new proposal, having the type parameters as () seems very > confusing, as now 3 things in a row use (): > > - Type parameters > > -

Re: [go-nuts] [generics] Closure?

Ah, this is https://golang.org/issue/39654. On Thursday, June 18, 2020 at 2:43:48 PM UTC-4 frave...@gmail.com wrote: > I think this probably gets a little closer to what you were going for, but > there's a puzzling error that leads me to think the parser doesn't quite > understand the

Re: [go-nuts] [generics] Replace () with <> or other character

On Thu, Jun 18, 2020 at 6:38 PM Brian Zhao wrote: > Would something similar work in go's parser? I'm personally in favor of > the <> syntax, since it's very similar to other languages (C++, Swift, > Rust, Java, C#). > > It is just another parameter. I wouldn't give it special syntactical

[go-nuts] [generics] Closure?

Hello, I didn't find in the latest draft design any mention of generics with closure and I'm struggling in having something working: type Foo(type T) struct {} func bar(type T)() Foo(T) { return func() Foo(T) { return Foo(T){} }() } In this example, how can I create a closure

Re: [go-nuts] [generics] replace ()/(type ) with :[]

On Thu, Jun 18, 2020 at 9:46 AM Kiswono Prayogo wrote: > Personally () parentheses seems like to be harder to read, too similar > with function calls. > This is exactly why I like it. These are parameters, and should be thought of just like other parameters in a function call. -- You received

[go-nuts] [generics] Angle brackets for generics?

Hello, I think, that default brackets will make code much less understandable. I'm suggesting to use angle brackets instead and omit the "type" word. For example, following function seems much more succinct for me: func Print (s []T) {} -- You received this message because you are subscribed to

[go-nuts] Re: How to make the first character in a string lowercase?

I think all other solutions works fine, but String Builder struct exists for the same reason. package main import ( "fmt" "strings" ) func ToLowerCase(str string) string { var b strings.Builder b.WriteString(strings.ToLower(string(str[0])))

[go-nuts] [generics] Feedback

https://go2goplay.golang.org/p/Ol5mbIbiZhX works good enough, finally a way to make go usable for my cases(work with collections)! There are two main things that we hope to learn 1) First, does generic code make sense? Does it feel like Go? What surprises do people encounter? Are the error

Re: [go-nuts] [generics] A Channel of a Generic Structure

Cool, it does work, thanks! Btw, thank you guys for your work. I know there are a lot of discussions going on but personally I'm very happy with generics so far. I'll keep working on my migration. On Thursday, 18 June 2020 00:39:02 UTC+2, Ian Lance Taylor wrote: > > On Wed, Jun 17, 2020 at

Re: [go-nuts] [generics] Replace () with <> or other character

Out of curiosity, would it be possible to have a workaround for the infinite lookahead problem? I happened to see a similar issue mentioned when implementing Swift Generics: https://github.com/apple/swift/blob/5bdc5ccd61cd43217e4f4e3515e32eb45e728df0/docs/Generics.rst#parsing-issues, and the

Re: [go-nuts] [generics] replace ()/(type ) with :[]

On Jun 18, 2020, at 12:30 PM, 'Thomas Bushnell, BSG' via golang-nuts wrote: > > On Thu, Jun 18, 2020 at 9:46 AM Kiswono Prayogo wrote: > Personally () parentheses seems like to be harder to read, too similar with > function calls. > > This is exactly why I like it. These are parameters, and

[go-nuts] Re: [generics] Closure?

Like this: https://go2goplay.golang.org/p/Veu_6glrHbn It is tricky that you need to write `(_ Foo(T))` as the returning value declaration. Otherwise, the current parser consider it as calling the function with argument T and returns a value of type Foo, or in case of `(Foo(T))`, it is

[go-nuts] Getting experience with type parameter parens

In a number of mailing list responses about various concerns or suggestions regarding the specific choice of parens for type parameters, Ian has responded a few times with: > Let's get some experience with this syntax before we decide to change it. What does this mean, exactly? For context, I,

Re: [go-nuts] [generics] the empty type list

The constraint can't be used for phantom types. If C is an interface with an empty type list and P is given by type P(type T C) struct{} you can't instantiate P because no type can satisfy C. C is not the type with 0 inhabitants: it's a constraint on types that cannot be satisfied. I don't

Re: [go-nuts] Getting experience with type parameter parens

On Thu, Jun 18, 2020 at 4:12 PM Brian Hatfield wrote: > > In a number of mailing list responses about various concerns or suggestions > regarding the specific choice of parens for type parameters, Ian has > responded a few times with: > > > Let's get some experience with this syntax before we

Re: [go-nuts] [generics] the empty type list

On Thu, Jun 18, 2020 at 4:19 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > Addendum: In Go, every type needs to be inhabited by at least one value - > it's zero value. And we already have a type that can take *exactly* one > value, namely struct{}. > That is true, but

Re: [go-nuts] [generics] Do we really need explicit type lists in constraints?

On Thu, Jun 18, 2020 at 4:59 PM Bruno Albuquerque wrote: > > It looks to me one point of contention on using interfaces instead of > contracts is the fact that now interfaces have to support type lists but only > when used as contracts. This, no matter how you slice it, looks ugly. I agree,

Re: [go-nuts] [generics] Do we really need explicit type lists in constraints?

On Thu, Jun 18, 2020 at 4:00 PM Bruno Albuquerque wrote: > > It looks to me one point of contention on using interfaces instead of > contracts is the fact that now interfaces have to support type lists but only > when used as contracts. This, no matter how you slice it, looks ugly. > > Now type

Re: [go-nuts] Port to powerpc 440fpu

On Thu, Jun 18, 2020 at 1:17 PM Hugo Cornelis wrote: > > Does anyone have experience with porting go applications to the powerpc > 440fpu 32 bit. > > We have a team that is porting the Docker tool suite to a device that uses > this CPU, we generated the system call bindings and compiled the

[go-nuts] go get golang.org/dl/go1.14.4 ?

I must be missing something.  Could someone please point me? kpixley@kpixley-mbp> go version go version go1.14.4 darwin/amd64 kpixley@kpixley-mbp> go get golang.org/dl/go1.14.4 kpixley@kpixley-mbp> type go1.14.4 bash: type: go1.14.4: not found kpixley@kpixley-mbp> go get golang.org/dl/go1.13.12

Re: [go-nuts] generics and absence of ability to specify correlated types

With the multitude of answers for use of alternative syntaxes for specifying type parameter lists, is there a chance that this concern could be addressed? thanks Dan On Wed, 2020-06-17 at 11:24 +, 'Dan Kortschak' via golang-nuts wrote: > Since this has come up again in [1], I would like to

[go-nuts] [generics] Do we really need explicit type lists in constraints?

It looks to me one point of contention on using interfaces instead of contracts is the fact that now interfaces have to support type lists but only when used as contracts. This, no matter how you slice it, looks ugly. Now type lists are there to support built-in operations like operators in

Re: [go-nuts] Generics: More on parens

Heh, I also run GMail+Chrome, but I see rectangles instead of blank spaces (see attachment), which only reinforces your point. On Fri, Jun 19, 2020 at 8:28 AM David Anderson wrote: > Here's one reason to not do that (screenshot from gmail, in a chrome with > a ton of unicode-ready fonts,

Re: [go-nuts] [generics] Replace () with <> or other character

On Wed, Jun 17, 2020 at 10:52 PM Brian Zhao wrote: > > Out of curiosity, would it be possible to have a workaround for the infinite > lookahead problem? > > I happened to see a similar issue mentioned when implementing Swift Generics: >

Re: [go-nuts] [generics] panic: unimplemented Spec *ast.TypeSpec

On Thu, Jun 18, 2020 at 3:22 PM Ryan Swanson wrote: > > Should this work? Is it just limitation of the translator? I was just > messing around, trying to port this version At first glance it seems like it should work. This looks like a bug in the translation tool. Please open a bug report.

[go-nuts] Re: [generics] Replace () with <> or other character

Not all languages use <> for parametric parametrism. I tried lots of variants and my favorite is [] from Scala (I don't like Scala, BTW). четверг, 18 июня 2020 г., 11:15:16 UTC+3 пользователь Nathanael Curin написал: > > An argument for this is also that (all ?) languages that use generics use

Re: [go-nuts] [generics] bring contracts back

> clear feedback on earlier versions of the design draft that contracts could be hard to understand. Yeah, sure. Now expect lots of materials throughout the web explaining "this part is for interface that is not supposed to be in a runtime but for compile time constraints". You understand

Re: [go-nuts] Generics: More on parens

Ian, I like the direction being taken on Generics, and I am thankful the Go Team did not rush into an implementation. I'm not a huge fan of another set of ()'s and I agree with not wanting the overhead of overloading <>. That got me thinking that we are in the 21st century. We all use editors

[go-nuts] Port to powerpc 440fpu

Hi all, Does anyone have experience with porting go applications to the powerpc 440fpu 32 bit. We have a team that is porting the Docker tool suite to a device that uses this CPU, we generated the system call bindings and compiled the Docker tool suite without much problems. Most of Docker

Re: [go-nuts] Re: How to make the first character in a string lowercase?

package main import ( "fmt" "unicode" ) func main() { fmt.Println(MakeFirstLowerCase("LikeThis")) } func MakeFirstLowerCase(s string) string { if len(s)==0 { return s } r := []rune(s) r[0] = unicode.ToLower(r[0]) return string(r) } On Thu, Jun 18, 2020 at 10:38 AM

Re: [go-nuts] [generics] the empty type list

Addendum: In Go, every type needs to be inhabited by at least one value - it's zero value. And we already have a type that can take *exactly* one value, namely struct{}. On Thu, Jun 18, 2020, 22:13 Axel Wagner wrote: > These arguments would be more convincing, if Go wouldn't already reject >

Re: [go-nuts] Generics: More on parens

Here's one reason to not do that (screenshot from gmail, in a chrome with a ton of unicode-ready fonts, displaying your email) : [image: lol.png] Also already addressed at https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use . - Dave On Thu,

Re: [go-nuts] [generics] why struct fields-based constraints were banned?

On Thu, Jun 18, 2020 at 1:45 PM Denis Cheremisov wrote: > > It would be much less troublesome if you would keep using contracts instead > of this interface insanity. I understand that you are not in favor of the new design draft, but some of the words you are using are on the aggressive side.

Re: [go-nuts] [generics] Closure?

I think this probably gets a little closer to what you were going for, but there's a puzzling error that leads me to think the parser doesn't quite understand the instantiation in the return type: https://go2goplay.golang.org/p/gcD609dr21E type Foo(type T) struct {} type

Re: [go-nuts] [generics] the empty type list

These arguments would be more convincing, if Go wouldn't already reject interfaces impossible to implement: https://play.golang.org/p/dYm8js26qml On Thu, Jun 18, 2020, 17:26 Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote: > It is a type which cannot be inhabited by a term. These

Re: [go-nuts] [generics] why struct fields-based constraints were banned?

It would be much less troublesome if you would keep using contracts instead of this interface insanity. четверг, 18 июня 2020 г., 3:18:05 UTC+3 пользователь Ian Lance Taylor написал: > > On Wed, Jun 17, 2020 at 10:05 AM Denis Cheremisov > > wrote: > > > > I can't get why struct based

[go-nuts] Re: [generics] Replace () with <> or other character

I agree -- 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. To view this discussion on the web visit

[go-nuts] [generics] panic: unimplemented Spec *ast.TypeSpec

Should this work? Is it just limitation of the translator? I was just messing around, trying to port this version -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] [generics] Angle brackets for generics?

On Thu, Jun 18, 2020 at 9:38 AM Павел Кошелев wrote: > > Hello, I think, that default brackets will make code much less > understandable. I'm suggesting to use angle brackets instead and omit the > "type" word. > > For example, following function seems much more succinct for me: func > Print

[go-nuts] Re: political fundraising on golang.org!

I thought, Everyone live matters. not just only Black. (White, yellow..) Did their lives matter? Golang stand only for black live matters. What about your country , you people. Russ cox, You are white, did you live matters? peterGo於 2020年6月14日星期日 UTC+8下午9時36分38秒寫道： > > Recently, a political

Re: [go-nuts] [generics] the empty type list

I think I'm missing something. How is nil not an inhabitant? On Thu, Jun 18, 2020 at 6:48 PM Bryan C. Mills wrote: > > On Thu, Jun 18, 2020 at 4:19 PM 'Axel Wagner' via golang-nuts > wrote: >> >> Addendum: In Go, every type needs to be inhabited by at least one value - >> it's zero value. And

Re: [go-nuts] [generics] go vet -generic flag

On Thu, Jun 18, 2020 at 12:30 AM Gert wrote: > > As far as I can tell there are already a lot of closed working as intended > tickets related to > > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#using-generic-types-as-unnamed-function-parameter-types

Re: [go-nuts] Help with code reproducing a change in Go 1.15 CL 229578

On Thu, Jun 18, 2020 at 1:54 AM Florin Pățan wrote: > > According to the Go 1.15 documentation, the change introduced in > https://golang.org/cl/229578 should change the program behavior, and users > are expected to perform modifications to their code. > > > Package unsafe's safety rules allow

Re: [go-nuts] Re: [generics] Type lists should be usable in any interface

On Wed, Jun 17, 2020 at 7:58 PM 'Bryan C. Mills' via golang-nuts wrote: > > On Wednesday, June 17, 2020 at 12:08:59 AM UTC-4 Ian Lance Taylor wrote: >> >> On Tue, Jun 16, 2020 at 9:04 PM Xie Zhenye wrote: >> > >> > I agree. constraint is different from normal interface. It's better to use >> >

Re: [go-nuts] Generics: More on parens

On Jun 18, 2020, at 6:19 PM, Jon Conradt wrote: > > Ian, I like the direction being taken on Generics, and I am thankful the Go > Team did not rush into an implementation. > > I'm not a huge fan of another set of ()'s and I agree with not wanting the > overhead of overloading <>. That got me

Re: [go-nuts] [generics] Thank you Go team

I'd like to add a big +1 here. The proposal around contracts and generics is solid from a conceptual perspective, and I enjoyed reading the rationale behind what's supported, and what isn't, and I think this is a wonderful addition to the language which keeps type safety in a very Go-like way

Re: [go-nuts] Re: [generics] (again). Type inference is somewhat weak

On Thu, Jun 18, 2020 at 12:23 AM roger peppe wrote: > > Yes, I agree. It seems to have trouble inferring types when the argument is a > generic interface type. > Here's a simpler example: https://go2goplay.golang.org/p/3-aVhD6Y9R2 > I think this is probably

[go-nuts] [generics] Thank you Go team

I doubt this will help, but I have to try... Really smart and accomplished people have worked for a year to refine the generics approach--as the impressive updated design draft and the scholarly FeatherweightGo paper both demonstrate. The design is accompanied with tools to allow development and

Re: [go-nuts] Go Generics using interfaces - alternative take

Hi Everyone, I saw the well written 16 June 2020 blog post The Next Step for Generics by Ian Lance Taylor and Robert Griesemer too. I agree, many people have said that Go needs generics, but we don’t necessarily know exactly what that means. If

Re: [go-nuts] Re: political fundraising on golang.org!

Please respect my request to let this thread drop. Thank you. 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 golang-nuts+unsubscr...@googlegroups.com. To

Re: [go-nuts] Re: political fundraising on golang.org!

Know your audience, and read the room. The message and how the message is delivered are distinct. Not executing on the latter obscures the former. Clearly this is a common problem for many on this subject. > On Jun 18, 2020, at 11:04 PM, Sam Whited wrote: > > On Thu, Jun 18, 2020, at

Re: [go-nuts] Re: political fundraising on golang.org!

I should rephrase that, "it's an important discussion *for this community*" and I think it's as important to expose this community to it as it is any other. On Fri, Jun 19, 2020, at 00:20, Ian Lance Taylor wrote: > On Thu, Jun 18, 2020 at 9:04 PM Sam Whited wrote: > > > > On Thu, Jun 18, 2020,

Re: [go-nuts] Re: political fundraising on golang.org!

On Thu, Jun 18, 2020 at 9:04 PM Sam Whited wrote: > > On Thu, Jun 18, 2020, at 22:00, 人间不值得 wrote: > > I thought, Everyone live matters. not just only Black. (White, > > yellow..) Did their lives matter? > > Of course they do. You seem, deliberately or not, to be missing the > obvious but

Re: [go-nuts] [generics] is generics with constrain needed ?

I'd also say that converting between []Foo and []Stringer isn't actually definable in a type-safe manner: https://blog.merovius.de/2018/06/03/why-doesnt-go-have-variance-in.html Slices are writable as well as readable, so if you could convert []Foo to []Stringer you'd also have to say what happens

[go-nuts] Re: [generics] Replace () with <> or other character

An argument for this is also that (all ?) languages that use generics use <>. It might make learning just easier for new Go developers that have experience from generics-compatible languages. Dimas -> Resembling other languages in some ways is not necessarily a bad thing, if the idea behind it

Re: [go-nuts] Re: [generics] (again). Type inference is somewhat weak

Yes, I agree. It seems to have trouble inferring types when the argument is a generic interface type. Here's a simpler example: https://go2goplay.golang.org/p/3-aVhD6Y9R2 I think this is probably https://github.com/golang/go/issues/39661 cheers, rog. On Thu, 18 Jun 2020 at 02:14, Denis

[go-nuts] [generics] go vet -generic flag

As far as I can tell there are already a lot of closed working as intended tickets related to https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#using-generic-types-as-unnamed-function-parameter-types My suggestion is to be more proactive about this

[go-nuts] Help with code reproducing a change in Go 1.15 CL 229578

According to the Go 1.15 documentation, the change introduced in https://golang.org/cl/229578 should change the program behavior, and users are expected to perform modifications to their code. > Package unsafe's safety rules allow converting an unsafe.Pointer into uintptr when calling certain

[go-nuts] Re: [generics] Why is constraint optional?

Yes, an alternative syntax I can come up with (underscore as a placeholder): func Foo(type T1 _, T2 Bar) On Thursday, 18 June 2020 03:28:39 UTC+1, Andrey Tcherepanov wrote: > > Wouldn't it be nice to have just > > func Foo(type T1, type T2 Bar) > > (type as keyword splitting it into 2 type