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

[Ian Lance Taylor]

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 
>> > type SomeConstraint constraint {} than type SomeConstraint interface {}
>>
>> That is an option, but then we would have two different concepts,
>> constraints and interfaces, that are very very similar. It's not
>> clear that that is better.
>
>
> I think we already have two very different concepts — we're just conflating 
> them together by giving them the same name.
> As far as I can tell, the semantics of non-type-list interface types and the 
> semantics of type-list interface types are not compatible.
>
> Today, if we have two interface types T1 and T2, with T1's method set is a 
> superset of T2's, then any value assignable to T1 is also assignable to T2: 
> that is, T1 is a subtype of (not just assignable to!) T2. That observation is 
> also reflected in the Featherweight Go paper, in which a type argument 
> satisfies a type constraint if (and only if) the argument is a subtype of the 
> constraint.
>
> Based on the semantics of type-lists in type constraints, I would expect that 
> a run-time interface type containing a type list would mean “an interface 
> value whose dynamic type is one of the listed types”, or perhaps “an 
> interface value whose dynamic type has one of the listed types as its 
> underlying type”. For consistency, such interfaces should also have the same 
> sort of subtyping relationship: if type T1's type-list is a strict subset of 
> T2's type-list, then any value assignable to T1 (including a variable of type 
> T1 itself!) should be assignable to T2.
>
> So, for example:
> type SmallInt interface { type int8, int16 }
> should be a subtype of
> type MediumInt interface { type int8, int16, int32 }
>
> However, in the current design draft, a constraint that is a type-list 
> interface allows use of the operators common to the types in the list.
> In the presence of type-list subtypes of interface types, the semantics for 
> those operators would be confusing at best. Consider the program:
>
> func Add(type T MediumInt)(x, y T) T {
> return x + y
> }
>
> func main() {
> var a int8 = 127
> var b int16 = 1
> fmt.Println(Add(SmallInt)(a, b))  // Should this print 128, or -128?
> }

I'm not sure whether it affects your point, but I want to point out
that this program is invalid.  The MediumInt type constraint accepts
any type whose underlying type is int8, int16, or int32.  The type
SmallInt, an interface type, is not one of those types.  So you are
not only extending the design draft to permit SmallInt to be an
ordinary interface type, you are extending the meaning of a type list
in a constraint to accept an interface type that implements the type
constraint.  That can't work, and this example shows why it can't
work: you can't add an int8 value and an int16 value.

This code is acting as though, if ordinary interface types could have
type lists, it would be OK to write

func Add2(x, y SmallInt) SmallInt { return x + y }

That is not OK, even though SmallInt has a type list.  Even though
every type in theSmallInt type list supports +, they don't support +
with every other type in the type list.


> So type-lists as they are defined in the current draft either cannot have the 
> subtyping properties of ordinary interfaces, or must have a meaning as type 
> constraints that is fundamentally different from their meaning as interfaces. 
> Either way, they don't seem at all consistent with ordinary interfaces to me, 
> so I would prefer that we not call them interfaces.

Maybe this is still true.  I'm not sure.  But I don't yet see a reason
to think that this is true.

Thanks.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW%2BM1nJyS8cLz1JFHCW17mjM09RCH6%2BDnWPO4A8TRGpTw%40mail.gmail.com.

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

[Ian Lance Taylor]

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 converting an unsafe.Pointer into 
> > uintptr when calling certain functions. Previously, in some cases, the 
> > compiler allowed multiple chained conversions (for example, 
> > syscall.Syscall(…, uintptr(uintptr(ptr)), …)). The compiler now requires 
> > exactly one conversion. Code that used multiple conversions should be 
> > updated to satisfy the safety rules.
>
> After reading that paragraph, I expect that the compiler fails to compile 
> code after that change. When running `go build` or `go build 
> -gcflags="-d=checkptr"` neither produce a failure. I used `go vet`, and that 
> doesn't catch this change either.
>
> The example I used is https://play.golang.org/p/a0B4kxLEAjb.
>
> Perhaps I failed to construct a correct example, in which case help would be 
> appreciated.
>
> I was not sure if this belongs to the mailing list or the issue tracker, so I 
> started here.

What has changed is that the compiler does not keep multiply-casted
pointers live across the call to syscall.Syscall.

Our assumption was that nobody actually wrote code like that.  Why
would they?  Do you know of any real code that does this?  If there is
no real code, then it doesn't seem worth spending the time to write
checks.  If we were going to do that, we might as well instead spend
the time to let the code continue to work.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXL-2A5yCBO8bDfyYfZMxuepg3e0J0koLHVsDYGgzLbrg%40mail.gmail.com.

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

[Ian Lance Taylor]

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
>
> My suggestion is to be more proactive about this specific problem as soon as 
> consensus is reached by introducing a `go vet -generic` flag that does 
> nothing more then just highlight this specific very rare problem. And 
> introduce this small language change now so it's more than a year in advance 
> in place.
>
> The concern I think will come forward is when we don't give it a high enough 
> priority early enough it will significantly handicap the generic error 
> compiler messages if we don't be concrete about it?

That sounds like a good plan, if we decide to proceed with this syntax.  Thanks.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU-%2BR9f5%3Dyo6Q72Y7KSirTT1d%2B0oipwv6CqdQFCkwfFfQ%40mail.gmail.com.

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

[Ian Lance Taylor]

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 https://github.com/golang/go/issues/39661

Is this related to
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference-for-generic-function-arguments
?

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcViF_1zZjPK4LBaXC0AivbMH%3DAB%3D2daPE46wqyJZBPq9Q%40mail.gmail.com.

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

[Sam Whited]

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, 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 implicit ", also". No one goes up to someone at a breast
> > cancer awareness march and says "what's wrong with you, don't you
> > know that colon cancer is important too?" so ask yourself why you
> > and so many others insist on doing this to the black lives matter
> > movement.
> >
> >
> > On Thu, Jun 18, 2020, at 23:59, Ian Lance Taylor wrote:
> > > Please respect my request to let this thread drop.
> >
> > This is an important discussion to have, I don't think it's fair or
> > appropriate to ask people to just drop it.
>
>
> It's an important discussion, but having it on golang-nuts is not
> working.
>
> It can continue off-list.
>
> Thanks.
>
> 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 view this discussion on the web
> visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXkA5OM%2BXcpMiJ6QNY48CE9ZUS6JophuSZ98Zs57n5-2g%40mail.gmail.com.
>

-- 
Sam Whited

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/cff66e28-ef98-48b7-ac19-694ad3a2a003%40www.fastmail.com.

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

[Ian Lance Taylor]

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 implicit ", also". No one goes up to someone at a breast
> cancer awareness march and says "what's wrong with you, don't you know
> that colon cancer is important too?" so ask yourself why you and so many
> others insist on doing this to the black lives matter movement.
>
>
> On Thu, Jun 18, 2020, at 23:59, Ian Lance Taylor wrote:
> > Please respect my request to let this thread drop.
>
> This is an important discussion to have, I don't think it's fair or
> appropriate to ask people to just drop it.


It's an important discussion, but having it on golang-nuts is not working.

It can continue off-list.

Thanks.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXkA5OM%2BXcpMiJ6QNY48CE9ZUS6JophuSZ98Zs57n5-2g%40mail.gmail.com.

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

[Robert Engels]

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 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 implicit ", also". No one goes up to someone at a breast
> cancer awareness march and says "what's wrong with you, don't you know
> that colon cancer is important too?" so ask yourself why you and so many
> others insist on doing this to the black lives matter movement.
> 
> 
>> On Thu, Jun 18, 2020, at 23:59, Ian Lance Taylor wrote:
>> Please respect my request to let this thread drop.
> 
> This is an important discussion to have, I don't think it's fair or
> appropriate to ask people to just drop it.
> 
> —Sam
> 
> -- 
> 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 
> https://groups.google.com/d/msgid/golang-nuts/4b013cd9-5e4a-405f-a136-69cb6b1ae8b2%40www.fastmail.com.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/5FCCEACB-6397-49B0-A3DB-EDE87489C1C3%40ix.netcom.com.

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

[Sam Whited]

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 implicit ", also". No one goes up to someone at a breast
cancer awareness march and says "what's wrong with you, don't you know
that colon cancer is important too?" so ask yourself why you and so many
others insist on doing this to the black lives matter movement.


On Thu, Jun 18, 2020, at 23:59, Ian Lance Taylor wrote:
> Please respect my request to let this thread drop.

This is an important discussion to have, I don't think it's fair or
appropriate to ask people to just drop it.

—Sam

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/4b013cd9-5e4a-405f-a136-69cb6b1ae8b2%40www.fastmail.com.

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

[Ian Lance Taylor]

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVZ8sfNDdhbw63YhbyT3WDGmWKXGbmfUKFyB5MPxpahRA%40mail.gmail.com.

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

[tomjamtin]

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 it means introducing generics 
into Go using interfaces as suggested by Arnaud Delobelle maybe that's OK. 
But If it means doing something like C++, Java, Erlang, Perl, Python, Lua 
etc then I hope it never ever happens. 


I also agree that it's important to ask if adding generics feels like Go? I 
thought Go was a reaction to the  C++, Java, others etc programming 
languages of the 1990's where their use of generics added significant 
complexity to both semantics and implementation. 


I know for some Go users having no generics sucks, but in my limited 
experience this happens rarely. Maps, slices, channels and interfaces are 
built in generic data structures and address many of my common use cases. 


Go is the first language I've learnt. What I really liked about it is its 
“less is more” approach. So far I'm not missing user-defined generics. I 
have gotten on fine without it. But if it is added at some point I will be 
forced to implement it because everyone else is, and that is something I am 
not looking forward to.


I see NOT having user-defined generics as a critical positive feature of Go 
and not something that is missing. Rather than focusing on what we can add 
to Go, maybe we should focus instead on how we can further improve Go by 
what else we can remove from Go?


Tom

On Wednesday, June 17, 2020 at 3:10:08 PM UTC+10, Ian Lance Taylor wrote:
>
> On Tue, Jun 16, 2020 at 1:54 PM Arnaud Delobelle 
> > wrote: 
> > 
> > I noticed today the blog post about the revised Generics proposal.  What 
> got me excited is this extract at the start: 
> > 
> > The biggest change is that we are dropping the idea of contracts. The 
> difference between contracts and interface types was confusing, so we’re 
> eliminating that difference. 
> > 
> > To me the lack of orthogonality between contracts and interfaces was the 
> major issue with the previous proposal and I have been musing with ways of 
> resolving it for a while, so I am very pleased that the proposal is going 
> down this path! 
> > 
> > Last month I decided to write a post about a way of introducing Generics 
> into Go using interfaces,  which I called "Package Specialization". 
> > 
> > Headline features are: 
> > 
> > use interfaces to express parametric types; 
> > no new keyword; 
> > the only new syntax is “package specialization”: pkg(T=int, 
> Y=*MyType).Func(); 
> > generic code which doesn’t use the package specialization syntax is 
> already valid Go. 
> > 
> > The full post can be read here: 
> https://arnodel.github.io/marooned/go/generics/2020/06/06/go-spec2.html 
> > 
> > I was toying with the idea of submitting it here for feedback, to try to 
> move the discussion in that direction.  Well, I guess today's updated 
> proposal steals my thunder! Essentially this is the same idea, but with a 
> different manifestation in the language - I thought that submitting it 
> anyway may provide a useful comparison point to help gauge the updated 
> proposal better. 
> > 
> > Note that sadly, I do not have much time to polish a proposal or to 
> follow discussions in general on this or other golang-related discussion 
> lists, so I apologize in advance if I am inadvertently re-hashing ideas 
> that have been put forward and dismissed in the past, or if my blog post is 
> a little low on detail (it was meant to be an exploration of a possible 
> approach). 
>
> Thanks.  I hadn't seen that before. 
>
> A difficulty with package specialization is when you want to write a 
> List(List(int)).  That is, a List where each element of the List is a 
> List(int).  Or, when you want to write a transformation function as in 
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#list-transform.
>  
>
> It would seem to require some modification of how imports work in Go, 
> and that leads into considerable complexity.  See also 
> .
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages
>  
> . 
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3d3f261f-cc94-4346-b31b-c6f740b133e4o%40googlegroups.com.

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

[jimmy frasche]

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 we already have a type that can take *exactly* one 
>> value, namely struct{}.
>
>
> That is true, but struct{} is the unit type — not the bottom element of the 
> interface-type lattice.
> struct{} can be added as a field of any struct with no effect on 
> comparability or equality, and adds no bits of information (it is a 
> multiplicative unit).
> As an interface value, struct{} carries one “bit” of information: its type.
> But struct{} has no methods and is not assignable to any interface type: 
> therefore, it is not the bottom type of the interface lattice.
>
> In contrast, the interface of the empty type-list, if such a thing could 
> exist at run-time, would presumably have only one value as well: the nil 
> interface value.
> The nil interface value is a member of every other interface type, so the 
> empty type-list would be assignable to every other interface type (it is the 
> bottom of the interface lattice).
> Conceptually, it has all possible methods, but there would be no point in 
> calling them: they all result in a nil-panic.
> As a struct field, the empty interface is also a multiplicative unit (it adds 
> no bits of information).
> However, it is also an additive unit: the union of the empty type-list and 
> any other interface is identical to the other interface (because every other 
> interface already admits the nil interface value).
>
>> On Thu, Jun 18, 2020, 22:13 Axel Wagner  
>> wrote:
>>>
>>> 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 
>>>  wrote:

 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 compile time restrictions.

 On Wed, Jun 17, 2020, 22:09 jimmy frasche  wrote:
>
> This isn't a bug per se, but I can file one if requested.
>
> https://go2goplay.golang.org/p/AWynhg6ya7h
>
> Since embedding interfaces with type lists uses the intersection of
> the items in the type list, it's possible to create an interface that
> cannot be satisfied by any type.
>
> Currently this does not cause an error until you attempt to
> instantiate something that uses such an interface as a bound.
>
> I think it would be more useful to raise the error when defining the
> interface that cannot be used as it's likely an error—or at least I
> can see no valid use for creating an unsatisfiable constraint.
>
> --
> 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 
> https://groups.google.com/d/msgid/golang-nuts/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%40mail.gmail.com.

 --
 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 
 https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com.
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/CsA1FJKZ4qs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFwkVmbva1bRYbHX3D6oUhufHvdr-Ebb0GY0u3j_fyTUA%40mail.gmail.com.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CANG3jXJX0gf%3D%3DniCa4MtQ7-3Q6rU%3DQr2tTpKntMVMqDVOo4BMw%40mail.gmail.com.

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

[Marcin Romaszewicz]

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
despite all the flexibility. It's really good language design, and the
syntax won't change what we can do with it. I look forward to simplifying a
lot of my code once this ships by reusing many data structures I've
implemented separately for many types. I have a whole team working on Go
code in production, so I just have to wait until it's shipped officially
and is stable.

Thank you Go Team. I was a Googler when Go was created, and I remember Rob
Pike saying that one of the reasons behind it was to keep programming fun,
to take out the drudge work, and it's been amazingly successful in that
regard.
-- Marcin

On Thu, Jun 18, 2020 at 7:17 PM Michael Jones 
wrote:

> 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 experience by any interested Go developer.
> This is marvelous. Thank you Go team and helpers!
>
> Let's post about substantial things in the design ("generic type switch
> necessary at day one" maybe, whatever) and not only about parenthesis. I'm
> going crazy here seeing all the comments about that. I mean, think of how
> hard they are working on this; parenthesis posts read like *More Cowbell *to
> me.
>
> Sorry for the outburst,
> Michael
>
> P.S. I challenge you to fully read the Featherweight Go paper and the
> design draft, as I did, and then come away thinking about the expression of
> the idea rather than the idea. I just can't comprehend it -- it is the
> ideas that hold power and beauty, that will transform our daily work.
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/CALoEmQyzv%3D4JxtJjpqC6R5u%3DkwjMtYH%3Die9H3KQYWyB3U%2B1Ybg%40mail.gmail.com
> 
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Ls78Z1whmeTm_XffQAb_cYOCv%2BObmPjAf7kV3ThTFJKwA%40mail.gmail.com.

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

[Michael Jones]

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 experience by any interested Go developer.
This is marvelous. Thank you Go team and helpers!

Let's post about substantial things in the design ("generic type switch
necessary at day one" maybe, whatever) and not only about parenthesis. I'm
going crazy here seeing all the comments about that. I mean, think of how
hard they are working on this; parenthesis posts read like *More Cowbell *to
me.

Sorry for the outburst,
Michael

P.S. I challenge you to fully read the Featherweight Go paper and the
design draft, as I did, and then come away thinking about the expression of
the idea rather than the idea. I just can't comprehend it -- it is the
ideas that hold power and beauty, that will transform our daily work.

-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQyzv%3D4JxtJjpqC6R5u%3DkwjMtYH%3Die9H3KQYWyB3U%2B1Ybg%40mail.gmail.com.

[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 message with a fundraising link appeared as a banner 
> atop golang.org websites: https://golang.org/, https://pkg.go.dev/.
>
> content/static: add Black Lives Matter banner to top of site
> https://go-review.googlesource.com/c/website/+/237589
>
> 
> Black Lives Matter.
> https://support.eji.org/give/153413/#!/donation/checkout";
>target="_blank"
>rel="noopener">Support the Equal Justice Initiative.
> 
>
> How was this decision made?
>
> Go is a programming language. For political fundraising use personal 
> Twitter and Facebook accounts. 
>
> Peter
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/30a4f999-42bd-4d72-840d-750a8649906ao%40googlegroups.com.

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

[David Riley]

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 thinking that we are in the 21st 
> century. We all use editors which are comfortable with Unicode. Why not take 
> advantage of characters beyond 7-bit ASCII?

The biggest reason, IMO: those are difficult to type on a keyboard.  What 
you're proposing here will be nearly impossible to type on any editor that 
doesn't have specialized support, which is a lot of them.  The keystrokes you 
propose (shift-opt-0/9) are Mac specific, since no one else has an Option key, 
and on my Terminal (on OS X) they result in the characters "·" and "‚" 
respectively, so I can't use them in vi.

The second-biggest reason is that they aren't guaranteed to display right 
everywhere (especially on screen readers, and I know we have a number of 
visually-impaired folks on this list for whom this is vitally important).  With 
apologies to those who can't view images, here is how this looks on my mail 
client in both proportional font (as received) and monospaced (as typed):






This will cause problems.  The authors of the proposal explicitly said they 
couldn't bring themselves to use something that's not ASCII, and I think that's 
still a valid decision.


- Dave

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/B2D47B12-F91B-4F87-8E20-33ACE5B35878%40gmail.com.

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

[Ian Lance Taylor]

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 (s []T) {}

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java

https://groups.google.com/d/msg/golang-nuts/Rumm5HFhg_Q/baIq7eDgBgAJ

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVLhLyM2vei9bG7kUiLDHPnh%3DsR-fmU0uwtW19asQQ9%2BQ%40mail.gmail.com.

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

['Bryan C. Mills' via golang-nuts]

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 struct{} is the unit type — not the bottom element of the
interface-type lattice.
struct{} can be added as a field of any struct with no effect on
comparability or equality, and adds no bits of information (it is a
multiplicative unit).
As an interface value, struct{} carries one “bit” of information: its type.
But struct{} has no methods and is not assignable to any interface type:
therefore, it is not the bottom type of the interface lattice.

In contrast, the interface of the empty type-list, if such a thing could
exist at run-time, would presumably have only one value as well: the nil
interface value.
The nil interface value is a member of every other interface type, so the
empty type-list would be assignable to every other interface type (it is
the bottom of the interface lattice).
Conceptually, it has all possible methods, but there would be no point in
calling them: they all result in a nil-panic.
As a struct field, the empty interface is also a multiplicative unit (it
adds no bits of information).
However, it is also an additive unit: the union of the empty type-list and
any other interface is identical to the other interface (because every
other interface already admits the nil interface value).

On Thu, Jun 18, 2020, 22:13 Axel Wagner 
> wrote:
>
>> 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 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 compile time restrictions.
>>>
>>> On Wed, Jun 17, 2020, 22:09 jimmy frasche 
>>> wrote:
>>>
 This isn't a bug per se, but I can file one if requested.

 https://go2goplay.golang.org/p/AWynhg6ya7h

 Since embedding interfaces with type lists uses the intersection of
 the items in the type list, it's possible to create an interface that
 cannot be satisfied by any type.

 Currently this does not cause an error until you attempt to
 instantiate something that uses such an interface as a bound.

 I think it would be more useful to raise the error when defining the
 interface that cannot be used as it's likely an error—or at least I
 can see no valid use for creating an unsatisfiable constraint.

 --
 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
 https://groups.google.com/d/msgid/golang-nuts/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%40mail.gmail.com
 .

>>> --
>>> 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
>>> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/CsA1FJKZ4qs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFwkVmbva1bRYbHX3D6oUhufHvdr-Ebb0GY0u3j_fyTUA%40mail.gmail.com
> 
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAKWVi_QQxkGAcdWNSozOeujF-vw2_mJNLuFibVN0JDsvByELcQ%40mail.gmail.com.

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

[Ian Lance Taylor]

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.  Thanks.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVeoSJsBzhorbqVv9Nb9qZQ28_L697Hms-WVme68L3s%3Dg%40mail.gmail.com.

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

[Ian Lance Taylor]

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: 
> https://github.com/apple/swift/blob/5bdc5ccd61cd43217e4f4e3515e32eb45e728df0/docs/Generics.rst#parsing-issues,
>  and the proposed workaround was:
>
>> We're going to try a variant of #1, using a variation of the disambiguation 
>> rule used in C#. Essentially, when we see:
>> identifier <
>> we look ahead, trying to parse a type parameter list, until parsing the type 
>> parameter list fails or we find a closing '>'. We then look ahead an 
>> additional token to see if the closing '>' is followed by a '(', '.', or 
>> closing bracketing token (since types are most commonly followed by a 
>> constructor call or static member access). If parsing the type parameter 
>> list succeeds, and the closing angle bracket is followed by a '(', '.', or 
>> closing bracket token, then the '<...>' sequence is parsed as a generic 
>> parameter list; otherwise, the '<' is parsed as an operator.
>
>
> 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 may be possible to do something like that in a Go parser.  But as
you can see it's complicated and hard to specify.  And let's not
forget about the >> issue when you write List>, the issue
being that >> is the right shift operator.  For many years C++
programmers had to write List >, and the fix for that syntax
tweak was really complex.  (But I don't know how Swift does it.)

Let's be clear: we may well change the syntax to stop using
parentheses for type lists.  But we aren't going to simply switch to
angle brackets.  That has too many complications.

Ian



> On Wed, Jun 17, 2020 at 5:50 PM 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
>> > - Function parameters/arguments
>> > - Return tuple
>> >
>> > This results in code like (from the draft):
>> > func Stringify(type T Stringer)(s []T) (ret []string) {
>> >   for _, v := range s {
>> > ret = append(ret, v.String())
>> >   }
>> >   return ret
>> > }
>> >
>> > Instead, using <> similar to other languages, makes it easier to visual 
>> > parse:
>> > func Stringify(s []T) (ret []string) {
>> >   for _, v := range s {
>> > ret = append(ret, v.String())
>> >   }
>> >   return ret
>> > }
>> >
>> > This can also apply to type definitions:
>> > type Vector []T
>> >
>> > To summarize:
>> > - Having 3 times () in a row makes it confusing to visual parse
>> > - The type keyword is not necessary
>> > - Using <> would make it friendly (and easier to recognize)
>>
>> Let's try the current suggested syntax and see how it works out in practice.
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
>>
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU%2B8XFLa7LU1Eaq_bYziAdBLxnR_WG19LLfcoN4qMh-ew%40mail.gmail.com.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW%2BCOAe-yK%2B%3D3HO%3Dp%3DBBWoqhtvq0H%2BMSobHpkCh_nLO3g%40mail.gmail.com.

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

[Nigel Tao]

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, 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, Jun 18, 2020 at 3:20 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 thinking that we are in the
>> 21st century. We all use editors which are comfortable with Unicode. Why
>> not take advantage of characters beyond 7-bit ASCII?
>>
>> http://xahlee.info/comp/unicode_matching_brackets.html
>>
>> I kind of like the 'fuzzy' nature of ⧙ and ⧘, but to try this out we
>> would need some investment from the Go Team.
>>
>> func Print⧙type T⧘(s []T) {
>> for _, v := range s {
>> fmt.Print(v)
>> }
>> }
>>
>> My experience with Generics is that you primarily author generic code
>> when you are building libraries, and as a developer you don't do that as
>> often as you use libraries. There is a cost to learning the new keystroke
>> (option-shift-9 and option-shift-0 in a properly configured editor).
>>
>> Jon
>>
>> On Wednesday, June 17, 2020 at 7:25:36 AM UTC-7 Aaron Cannon wrote:
>>
>>> Thanks Ian for the reply.
>>>
>>> I certainly understand wanting to get more experience with the
>>> proposed syntax, but I still don't think the trade-offs are worth it.
>>> In particular, I remain concerned about the cognitive load of using
>>> parens in yet another context, and the (IMHO) unnecessary breaking of
>>> backwards compatibility, even if only in very few cases.
>>>
>>> Moving away from parens to something like what I proposed would, I
>>> believe, remove all the ambiguities identified in the proposal. var f
>>> func(x(T)) would become the unambiguous var f func(x.)
>>>
>>> x2 := []T.{} as opposed to needing yet another set of parens.
>>>
>>> And so on for the other parsing ambiguities mentioned in the proposal.
>>>
>>> To be clear, I don't think it has to be the syntax I propose, but I do
>>> think it should be easily recognizable as unique by the parser and
>>> humans alike.
>>>
>>> The reason I favor the <> syntax is that <> is well known from C++
>>> (and maybe other languages?) as denoting something dealing with
>>> generics. I also like the .<> for instantiation because it resembles
>>> type assertion .(). Type assertion is essentially collapsing a broader
>>> type to a narrower type, which is sort of what type instantiation is
>>> doing if you squint a bit. :)
>>>
>>> Anyway, just my $0.02. Thanks again for all the hard work on this.
>>>
>>> Aaron
>>>
>>> On 6/16/20, Ian Lance Taylor  wrote:
>>> > On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon
>>> >  wrote:
>>> >>
>>> >> I, like many others, am not fond of all the parenthesis, particularly
>>> at
>>> >> call sites. I think at definition sites, it's not so bad. It seems
>>> like
>>> >> the only objection to < and > are the complexity it adds for parsing.
>>> It
>>> >> also seems like the only place it adds ambiguity is at call or
>>> >> enstantiation sites. So what if we used .>> >> Print(string)(stringSlice) we would do Print.(stringSlice) I
>>> think
>>> >> definitions could just swap () for < > for generic type parameters,
>>> >> without the dot.
>>> >> Aside from that, and wishing that the proposal specified that
>>> generics
>>> >> would all be resolved at compile time rather than at run time, I'm
>>> really
>>> >> loving this!
>>> >
>>> > Thanks for the note. I think we should get some experience with
>>> > writing code using this syntax before we discard it.
>>> >
>>> > 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/5e32c71c-43f5-494e-9de6-ba96bce00e8en%40googlegroups.com
>> 
>> .
>>
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/CAMx%2Br7XuXpbXeRXPedh6x8FF0UoNLmiEkTTRBS40MN6DyUFZDw%40mail.gmail.com
> 

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

[Ian Lance Taylor]

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 Docker tool 
> suite without much problems.
>
> Most of Docker seems to be working fine on the device, however interactive 
> terminal input/output is not working.
>
> Investigation shows that two specific goroutines that are responsible for 
> forwarding the I/O between two Docker related processes are not scheduled 
> (they don't receive CPU cycles) until after Docker terminates these process 
> with a signal 15 (TERM) and the two goroutines are suddenly scheduled and all 
> of the output buffers are suddenly flushed to the terminal.
>
> We have looked at the terminal settings and flags applied to the file 
> descriptors and these seem all fine (although I must admit that the code 
> flows inside Docker and its tools are complicated).
>
> We suspect there may be a problem with one or more of the system call 
> bindings, for instance that there may be a system call declared with //sysnb 
> where it should be just //sys, if that makes sense.  I would actually not 
> know how to distinguish between these two flags.
>
> We would now like to inspect the status of the two goroutines to understand 
> what they are waiting for, and why the scheduler does not schedule them.
>
> Debugging with GODEBUG=schedtrace=1000;scheddetail=1, helps somewhat but no 
> idea how to relate the output of the scheduler state to the two goroutines 
> (if it would make sense at all).
>
> Does anyone have any experience debugging this type of problem?  How would we 
> look at where exactly these processes are blocked without developing core 
> knowledge about the Docker tool suite?
>
> We have been working on this for several weeks now, any help would be greatly 
> appreciated.


The standard Go distribution doesn't support 32-bit PPC, so I feel
like there is some missing background information here.

If the problem is with making system calls, then it often helps to
look at the "strace -f" output to see what is going on at the system
call level.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVMV_ya4vWw9faj9ebTQxegbQbksGjkf2w4eZbgUG2KVg%40mail.gmail.com.

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

[Ian Lance Taylor]

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 lists are there to support built-in operations like operators in 
> general and range support. there is a finite (and relatively small) set of 
> combinations of types that make sense.
>
> Also there is already the intention of providing "contracts" like Comparable 
> in pre-existing libraries.
>
> There is also precedent for "magical" things in the language (range can 
> operate on slices of any type).
>
> So, with all that in mind, wouldn't it be possible for the language to offer 
> all the possible reasonable type combinations as built-in contracts in a way 
> that they could be embedded in other interfaces? They would be a bit magical 
> as their constraints are, under the hood, on types (not methods), but I guess 
> this would make things less ugly.


Thanks.  It's not as easy as it sounds.  There are many different type
combinations in Go.  It winds up being something like 25 new names to
add to the language.  That is a lot.

Also, consider cases like
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#composite-types-in-constraints
.  With those you get even more cases.

It's likely that in practice the common constraints will be in a
standard library constraints package, so relatively few people will
write type lists.  But the constraints package can be written in Go,
which is nice, and people will be able to reach for complex cases with
their own type lists when they need them, which is also nice.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUfvOLaOG_q%3DFgSWrSq9eA8z26Dj%2BCBKH6js23L5i2h8w%40mail.gmail.com.

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

[Ian Lance Taylor]

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 decide to change it.
>
> What does this mean, exactly?
>
> For context, I, as I am sure you are, am seeing a lot of feedback about the 
> choice of parens for this - on the mailing list, on Twitter, privately from 
> peers, and even my own self doubt of feeling a bit uncertain about if I am 
> reading the syntax correctly.
>
> At what point is that feedback actionable? Is there a plan for making a 
> decision before it's more difficult to change?
>
> For clarity, I have read the design document, both a year ago, and the 
> current revision, because I am very excited about the work that is being 
> done. I've played with the playground, and read a few other examples and 
> posts folks have written about the current draft.
>
> I still feel a bit uncertain/uncomfortable. I also think initial reactions 
> are valuable, because they can show us how immediately understandable choices 
> are, which is important as Go welcomes new or casual developers.
>
> TL;DR: what's next for that specific design decision?


What I mean is: write some code using the syntax described in the
design draft.  See what that code looks like.  See if it is readable.
See if the parentheses are confusing.

The syntax used for type parameters and type arguments is the very
first thing that people will encounter when looking at generic code.
The proposed syntax is unlike that used in most other languages.
Therefore, it is the first thing that will concern people looking at
the design draft and the first thing that they will comment on.

The fact that the syntax is unusual means that people will comment but
it doesn't in itself mean that the syntax is bad.  Of course, the
syntax may be bad.  But we can't judge that by people's first
reaction.  We can only judge that by people writing real code.  We
need experience with code to know whether the syntax can work.

So, let's get some experience with this syntax before we decide to
change it.  Experience, not just first impressions.

I understand your comment that initial reactions are valuable, but I
think that thoughtful experiences are more valuable.  There are many
first reactions that people have to Go that cause them to bounce off
the language, like the fact that braces must be at the end of the
line, or that exporting of identifiers is done using an initial
capital letter, or that in declarations names appear before the type.
We saw many comments about those topics in the early days of Go.  But
as people got used to these ideas, and they turned out to be OK.
Perhaps parentheses for type arguments will also turn out OK.  Perhaps
not.  We'll see.

You express a concern that it's difficult to change the syntax, but
it's not.  It's trivial.  If we keep the basic idea of type parameters
and type arguments, it will be easy to automatically rewrite any code
that anyone cares about to some new syntax.  The current syntax is not
an emergency.

For that matter, if anybody has any suggestions for a different
syntax, by all means send them in.  But please try to look at the
syntaxes that have already been proposed.  I'm seeing the same ideas
multiple times, including ideas that are discussed in the design
draft.  If you want to help, please take the time to do some research,
and try writing some code with the syntax.  Consider particular cases
like functions with type parameters but no non-type parameters.

I hope that makes my position clearer.  Thanks.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVRkQwt992B_SAZJkOY401MX7Yh4W4vuCbuc0pRXWZ69w%40mail.gmail.com.

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

[jimmy frasche]

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 see how it can be used in any valid program or why it would be
hard to detect. I am a little fuzzy on when type lists bring the
underlying type into play, though.

On Thu, Jun 18, 2020 at 1:17 PM Axel Wagner
 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{}.
>
> On Thu, Jun 18, 2020, 22:13 Axel Wagner  wrote:
>>
>> 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 
>>  wrote:
>>>
>>> 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 compile time restrictions.
>>>
>>> On Wed, Jun 17, 2020, 22:09 jimmy frasche  wrote:

 This isn't a bug per se, but I can file one if requested.

 https://go2goplay.golang.org/p/AWynhg6ya7h

 Since embedding interfaces with type lists uses the intersection of
 the items in the type list, it's possible to create an interface that
 cannot be satisfied by any type.

 Currently this does not cause an error until you attempt to
 instantiate something that uses such an interface as a bound.

 I think it would be more useful to raise the error when defining the
 interface that cannot be used as it's likely an error—or at least I
 can see no valid use for creating an unsatisfiable constraint.

 --
 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 
 https://groups.google.com/d/msgid/golang-nuts/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%40mail.gmail.com.
>>>
>>> --
>>> 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 
>>> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CANG3jX%2BESnanNyPBdDdQdc_uZMFzU-h3fMRGqB01M-RJVtnSaQ%40mail.gmail.com.

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

[burak serdar]

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, it looks ugly.

I wrote a proposal (first proposal?) about a year ago about these type
lists. The idea with type lists had two aspects then: first, you have
to somehow use primitive types as constraints without operator
overloading, and second, you can use existing types as constraints
instead of dealing with type traits. I understand that the concept of
contracts could be confusing. But I believe changing the definition of
interfaces would be even more confusing. Interfaces already cause a
lot of problems for people coming from other languages like Java.

One suggestion could be using type lists where needed:

func f(type T int string bool) (input T)

This can get verbose, so maybe a new keyword?

typelist TL int, string,bool
func f(type T TL)(input T)

This goes back to contracts though. Maybe "contract" could be renamed
to less confusing "typelist"?

Also, there is no point in restricting typelist to primitives:

typelist TL int, string, bool, SomeInterface

I think such a typelist can do everything the interface-with-typelist
can without changing the definition of what interface means.

Just some thoughts, I'm still reading the design doc...

>
> Now type lists are there to support built-in operations like operators in 
> general and range support. there is a finite (and relatively small) set of 
> combinations of types that make sense.
>
> Also there is already the intention of providing "contracts" like Comparable 
> in pre-existing libraries.
>
> There is also precedent for "magical" things in the language (range can 
> operate on slices of any type).
>
> So, with all that in mind, wouldn't it be possible for the language to offer 
> all the possible reasonable type combinations as built-in contracts in a way 
> that they could be embedded in other interfaces? They would be a bit magical 
> as their constraints are, under the hood, on types (not methods), but I guess 
> this would make things less ugly.
>
> --
> 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 
> https://groups.google.com/d/msgid/golang-nuts/CAEd86Tz%2B6vfp1C_kFA82Mw5z__%3D5SLrc%3Dnu3od1AKBVCCRtBPQ%40mail.gmail.com.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAMV2RqrSqTkYkxmk8EKAw%3D4_9ECWguNZGN_1W9Z2AmXk0Zz9AA%40mail.gmail.com.

[go-nuts] Getting experience with type parameter parens

[Brian Hatfield]

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, as I am sure you are, am seeing a *lot* of feedback about
the choice of parens for this - on the mailing list, on Twitter, privately
from peers, and even my own self doubt of feeling a bit uncertain about if
I am reading the syntax correctly.

At what point is that feedback actionable? Is there a plan for making a
decision before it's more difficult to change?

For clarity, I have read the design document, both a year ago, and the
current revision, because I am very excited about the work that is being
done. I've played with the playground, and read a few other examples and
posts folks have written about the current draft.

I still feel a bit uncertain/uncomfortable. I also think initial reactions
are valuable, because they can show us how immediately understandable
choices are, which is important as Go welcomes new or casual developers.

TL;DR: what's next for that specific design decision?

Thank you!
Brian

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CANGiwgasGn-N-2u%2BxYdaNofzzqZwpn7hbV7Kvr8i5c9cjUdvyw%40mail.gmail.com.

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

[Bruno Albuquerque]

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
general and range support. there is a finite (and relatively small) set of
combinations of types that make sense.

Also there is already the intention of providing "contracts" like
Comparable in pre-existing libraries.

There is also precedent for "magical" things in the language (range can
operate on slices of any type).

So, with all that in mind, wouldn't it be possible for the language to
offer all the possible reasonable type combinations as built-in contracts
in a way that they could be embedded in other interfaces? They would be a
bit magical as their constraints are, under the hood, on types (not
methods), but I guess this would make things less ugly.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAEd86Tz%2B6vfp1C_kFA82Mw5z__%3D5SLrc%3Dnu3od1AKBVCCRtBPQ%40mail.gmail.com.

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

['Dan Kortschak' via golang-nuts]

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 re-raise the
> issue
> of being able to correlate float and complex types so that a
> func(float32) complex64/func(float64) complex128-like function can be
> written generically. This issue was raised in [2] in the last round
> of
> generics discussions with the example now in [3] and [4].
> 
> This wasn't addressed last time, and it does not appear to be
> addressed
> in the current document, although the Point method section comes sort
> of close[5] by doing essentially the same kind of
> conversion/constraint
> but with pointers, also the `ComplexAbs(type T Complex) T` type,
> however this does not handle both the cases below and achieves what
> it
> does in a heavier way.
> 
> Dan
> 
> [1]
> 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md
> [2]
> https://groups.google.com/d/msg/golang-dev/nug_hZnGQog/et4aKG6_DAAJ
> [3]https://go2goplay.golang.org/p/gdJNbVmLy8u
> [4]https://go2goplay.golang.org/p/Ak6q0CfUT7d
> [5]
> 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#pointer-methods
> 
> 
> --
> 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 
> https://groups.google.com/d/msgid/golang-nuts/59e4349d3c0811462c153c4b5905d884b37e442e.camel%40kortschak.io
> .


-- 
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 
https://groups.google.com/d/msgid/golang-nuts/10381f7fa1b2aefe88ccf447a70eee17d6cc13bd.camel%40kortschak.io.

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

[Ian Lance Taylor]

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.  Please be
mindful of our code of conduct (https://golang.org/conduct) and
express your disagreement in more respectful ways.  We are all working
to make Go better.

Thanks.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXctTYSJB-pBT%3D_TpQEeKdEzM7Jv91ZV6MGyB1-d526EA%40mail.gmail.com.

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

[David Anderson]

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, Jun 18, 2020 at 3:20 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 thinking that we are in the 21st
> century. We all use editors which are comfortable with Unicode. Why not
> take advantage of characters beyond 7-bit ASCII?
>
> http://xahlee.info/comp/unicode_matching_brackets.html
>
> I kind of like the 'fuzzy' nature of ⧙ and ⧘, but to try this out we
> would need some investment from the Go Team.
>
> func Print⧙type T⧘(s []T) {
> for _, v := range s {
> fmt.Print(v)
> }
> }
>
> My experience with Generics is that you primarily author generic code when
> you are building libraries, and as a developer you don't do that as often
> as you use libraries. There is a cost to learning the new keystroke
> (option-shift-9 and option-shift-0 in a properly configured editor).
>
> Jon
>
> On Wednesday, June 17, 2020 at 7:25:36 AM UTC-7 Aaron Cannon wrote:
>
>> Thanks Ian for the reply.
>>
>> I certainly understand wanting to get more experience with the
>> proposed syntax, but I still don't think the trade-offs are worth it.
>> In particular, I remain concerned about the cognitive load of using
>> parens in yet another context, and the (IMHO) unnecessary breaking of
>> backwards compatibility, even if only in very few cases.
>>
>> Moving away from parens to something like what I proposed would, I
>> believe, remove all the ambiguities identified in the proposal. var f
>> func(x(T)) would become the unambiguous var f func(x.)
>>
>> x2 := []T.{} as opposed to needing yet another set of parens.
>>
>> And so on for the other parsing ambiguities mentioned in the proposal.
>>
>> To be clear, I don't think it has to be the syntax I propose, but I do
>> think it should be easily recognizable as unique by the parser and
>> humans alike.
>>
>> The reason I favor the <> syntax is that <> is well known from C++
>> (and maybe other languages?) as denoting something dealing with
>> generics. I also like the .<> for instantiation because it resembles
>> type assertion .(). Type assertion is essentially collapsing a broader
>> type to a narrower type, which is sort of what type instantiation is
>> doing if you squint a bit. :)
>>
>> Anyway, just my $0.02. Thanks again for all the hard work on this.
>>
>> Aaron
>>
>> On 6/16/20, Ian Lance Taylor  wrote:
>> > On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon
>> >  wrote:
>> >>
>> >> I, like many others, am not fond of all the parenthesis, particularly
>> at
>> >> call sites. I think at definition sites, it's not so bad. It seems
>> like
>> >> the only objection to < and > are the complexity it adds for parsing.
>> It
>> >> also seems like the only place it adds ambiguity is at call or
>> >> enstantiation sites. So what if we used .> >> Print(string)(stringSlice) we would do Print.(stringSlice) I
>> think
>> >> definitions could just swap () for < > for generic type parameters,
>> >> without the dot.
>> >> Aside from that, and wishing that the proposal specified that generics
>> >> would all be resolved at compile time rather than at run time, I'm
>> really
>> >> loving this!
>> >
>> > Thanks for the note. I think we should get some experience with
>> > writing code using this syntax before we discard it.
>> >
>> > 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5e32c71c-43f5-494e-9de6-ba96bce00e8en%40googlegroups.com
> 
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAMx%2Br7XuXpbXeRXPedh6x8FF0UoNLmiEkTTRBS40MN6DyUFZDw%40mail.gmail.com.

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

[Ryan Swanson]

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 
"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 
https://groups.google.com/d/msgid/golang-nuts/75edf7b1-9ad9-4782-ab80-424d38aa3767o%40googlegroups.com.

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

[Backend Ninja]

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 
https://groups.google.com/d/msgid/golang-nuts/cd3a89d4-1f3d-4993-81df-7501e32eaf27o%40googlegroups.com.

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

[Jon Conradt]

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 which are comfortable with Unicode. Why not 
take advantage of characters beyond 7-bit ASCII?

http://xahlee.info/comp/unicode_matching_brackets.html

I kind of like the 'fuzzy' nature of ⧙ and ⧘, but to try this out we would 
need some investment from the Go Team. 

func Print⧙type T⧘(s []T) {
for _, v := range s {
fmt.Print(v)
}
}

My experience with Generics is that you primarily author generic code when 
you are building libraries, and as a developer you don't do that as often 
as you use libraries. There is a cost to learning the new keystroke 
(option-shift-9 and option-shift-0 in a properly configured editor).

Jon

On Wednesday, June 17, 2020 at 7:25:36 AM UTC-7 Aaron Cannon wrote:

> Thanks Ian for the reply.
>
> I certainly understand wanting to get more experience with the
> proposed syntax, but I still don't think the trade-offs are worth it.
> In particular, I remain concerned about the cognitive load of using
> parens in yet another context, and the (IMHO) unnecessary breaking of
> backwards compatibility, even if only in very few cases.
>
> Moving away from parens to something like what I proposed would, I
> believe, remove all the ambiguities identified in the proposal. var f
> func(x(T)) would become the unambiguous var f func(x.)
>
> x2 := []T.{} as opposed to needing yet another set of parens.
>
> And so on for the other parsing ambiguities mentioned in the proposal.
>
> To be clear, I don't think it has to be the syntax I propose, but I do
> think it should be easily recognizable as unique by the parser and
> humans alike.
>
> The reason I favor the <> syntax is that <> is well known from C++
> (and maybe other languages?) as denoting something dealing with
> generics. I also like the .<> for instantiation because it resembles
> type assertion .(). Type assertion is essentially collapsing a broader
> type to a narrower type, which is sort of what type instantiation is
> doing if you squint a bit. :)
>
> Anyway, just my $0.02. Thanks again for all the hard work on this.
>
> Aaron
>
> On 6/16/20, Ian Lance Taylor  wrote:
> > On Tue, Jun 16, 2020 at 8:31 PM Aaron Cannon
> >  wrote:
> >>
> >> I, like many others, am not fond of all the parenthesis, particularly at
> >> call sites. I think at definition sites, it's not so bad. It seems like
> >> the only objection to < and > are the complexity it adds for parsing. It
> >> also seems like the only place it adds ambiguity is at call or
> >> enstantiation sites. So what if we used . >> Print(string)(stringSlice) we would do Print.(stringSlice) I 
> think
> >> definitions could just swap () for < > for generic type parameters,
> >> without the dot.
> >> Aside from that, and wishing that the proposal specified that generics
> >> would all be resolved at compile time rather than at run time, I'm 
> really
> >> loving this!
> >
> > Thanks for the note. I think we should get some experience with
> > writing code using this syntax before we discard it.
> >
> > 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5e32c71c-43f5-494e-9de6-ba96bce00e8en%40googlegroups.com.

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

['K Richard Pixley' via golang-nuts]

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
kpixley@kpixley-mbp> type go1.13.12
bash: type: go1.13.12: not found
kpixley@kpixley-mbp> go get golang.org/dl/go1.15beta1
kpixley@kpixley-mbp> type go1.15beta1
bash: type: go1.15beta1: not found

--
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 
https://groups.google.com/d/msgid/golang-nuts/e4ec57c1-7234-457a-bdff-6448bcde0e34%40juniper.net.

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

[Denis Cheremisov]

> 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 better than me albeit these 
concepts (interfaces and contractrs) has a lot in common they are not the 
same. At last, take your language as an example: it shines as a glue 
between services and its set of primitives (goroutines, channels, full 
async) is what made it so successful in this domain. But you won't try to 
use it for serious Linux kernel module. You won't even try these primitives 
for GUI development (which also has asynchronous nature) because they have 
a huge overweight for the task.



PS I am afraid these people I were listening also want <> 


четверг, 18 июня 2020 г., 1:11:22 UTC+3 пользователь Ian Lance Taylor 
написал:
>
> On Wed, Jun 17, 2020 at 9:58 AM Denis Cheremisov 
> > wrote: 
> > 
> > IMO a groups of constraints are horrible with interfaces 
> > 
> > type CommonResponse(type E) interface { 
> > GetError() E 
> > } 
> > 
> > type CommonError interface { 
> > GetCode() int32 
> > } 
> > 
> > func IsOK(type R CommonResponse(E), E CommonError)(r R) bool { 
> > switch r.GetError().GetCode() { 
> > case 0, 200, 201: 
> > return true 
> > default: 
> > return false 
> > } 
> > } 
> > 
> > vs 
> > 
> > constract CommmonResponse(R, E) { 
> > R GetError() E 
> > E GetCode() int32 
> > } 
> > 
> > func IsOK(type R, E CommonResponse)(r R) bool { 
> > switch r.GetError().GetCode() { 
> > case 0, 200, 201: 
> > return true 
> > default: 
> > return false 
> > } 
> > } 
> > 
> > That trickery with commas to express dependcy of types is hard 
>
>
> I think there is no question that complex cases are more difficult to 
> express using parameterized interfaces as constraints. 
>
> But the overall change to the language seems to be simpler.  There was 
> clear feedback on earlier versions of the design draft that contracts 
> could be hard to understand.  And with parameterized interfaces as 
> constraints it is still possible to express the complex cases, albeit 
> in a more complicated way.  It's OK if complicated are hard to 
> express, as long as they remain possible. 
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/50d5375c-1698-4006--9ac3a6c84d1do%40googlegroups.com.

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

[Denis Cheremisov]

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 constraints were banned. struct is a kind 
> of types in Go and a wish to only allow them having some field is valid. 
>
> I'm not sure I would say that they were banned, it's just that we 
> haven't seen a good way to fit them into the notion of interface types 
> as constraints. 
>
> It's not clear how important this is.  It's not clear how often this 
> really comes up in practice. 
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/eccb23d1-5d14-4508-b52e-eb715511bbb2o%40googlegroups.com.

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

[Denis Cheremisov]

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 
> <>. 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 makes sense.
>
> Le mercredi 17 juin 2020 18:36:10 UTC+2, Charles Crete a écrit :
>>
>> Based on the new proposal, having the type parameters as () seems very 
>> confusing, as now 3 things in a row use ():
>> - Type parameters
>> - Function parameters/arguments
>> - Return tuple
>>
>> This results in code like (from the draft):
>> func Stringify(type T Stringer)(s []T) (ret []string) {
>>   for _, v := range s {
>> ret = append(ret, v.String())
>>   }
>>   return ret
>> }
>>
>> Instead, using <> similar to other languages, makes it easier to visual 
>> parse:
>> func Stringify(s []T) (ret []string) {
>>   for _, v := range s {
>> ret = append(ret, v.String())
>>   }
>>   return ret
>> }
>>
>> This can also apply to type definitions:
>> type Vector []T
>>
>> To summarize:
>> - Having 3 times () in a row makes it confusing to visual parse
>> - The type keyword is not necessary
>> - Using <> would make it friendly (and easier to recognize)
>>
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/72815259-77ba-4ac8-b5c3-1e4943a08d47o%40googlegroups.com.

[go-nuts] Port to powerpc 440fpu

[Hugo Cornelis]

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 seems to be working fine on the device, however interactive 
terminal input/output is not working.

Investigation shows that two specific goroutines that are responsible for 
forwarding the I/O between two Docker related processes are not scheduled 
(they don't receive CPU cycles) until after Docker terminates these process 
with a signal 15 (TERM) and the two goroutines are suddenly scheduled and 
all of the output buffers are suddenly flushed to the terminal.

We have looked at the terminal settings and flags applied to the file 
descriptors and these seem all fine (although I must admit that the code 
flows inside Docker and its tools are complicated).

We suspect there may be a problem with one or more of the system call 
bindings, for instance that there may be a system call declared with 
//sysnb where it should be just //sys, if that makes sense.  I would 
actually not know how to distinguish between these two flags.

We would now like to inspect the status of the two goroutines to understand 
what they are waiting for, and why the scheduler does not schedule them.

Debugging with GODEBUG=schedtrace=1000;scheddetail=1, helps somewhat but no 
idea how to relate the output of the scheduler state to the two goroutines 
(if it would make sense at all).

Does anyone have any experience debugging this type of problem?  How would 
we look at where exactly these processes are blocked without developing 
core knowledge about the Docker tool suite?

We have been working on this for several weeks now, any help would be 
greatly appreciated.

Thanks!

Hugo


-- 
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 
https://groups.google.com/d/msgid/golang-nuts/3acc9a80-acfe-447b-a8f9-1d33b00b48cco%40googlegroups.com.

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

[leo]

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  wrote:

> 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])))
> b.WriteString(str[1:])
>
> return b.String()
>
> }
>
> func main() {
> var str string = "GoLang"
> fmt.Println(ToLowerCase(str))
> }
>
>
>
> Playground here: https://play.golang.org/p/aAyBGnM5p2x
>
> On Saturday, 24 November 2012 11:51:23 UTC+1, Nikolai wrote:
>>
>> Hi!
>>
>> What is the easiest way to make a string "LikeThis" --> "likeThis"?
>>
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/59ede7f8-bfb9-44a0-9fa7-cef1d7288983o%40googlegroups.com
> 
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAN7WhqjEmDQ7Z%3DuRUzUz0CrdNYUkCnyOdxd4GqazbUB16DmcRw%40mail.gmail.com.

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

['Axel Wagner' via golang-nuts]

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
> 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 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 compile time restrictions.
>>
>> On Wed, Jun 17, 2020, 22:09 jimmy frasche 
>> wrote:
>>
>>> This isn't a bug per se, but I can file one if requested.
>>>
>>> https://go2goplay.golang.org/p/AWynhg6ya7h
>>>
>>> Since embedding interfaces with type lists uses the intersection of
>>> the items in the type list, it's possible to create an interface that
>>> cannot be satisfied by any type.
>>>
>>> Currently this does not cause an error until you attempt to
>>> instantiate something that uses such an interface as a bound.
>>>
>>> I think it would be more useful to raise the error when defining the
>>> interface that cannot be used as it's likely an error—or at least I
>>> can see no valid use for creating an unsatisfiable constraint.
>>>
>>> --
>>> 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
>>> https://groups.google.com/d/msgid/golang-nuts/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%40mail.gmail.com
>>> .
>>>
>> --
>> 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
>> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com
>> 
>> .
>>
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFwkVmbva1bRYbHX3D6oUhufHvdr-Ebb0GY0u3j_fyTUA%40mail.gmail.com.

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

['Axel Wagner' via golang-nuts]

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 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 compile time restrictions.
>
> On Wed, Jun 17, 2020, 22:09 jimmy frasche  wrote:
>
>> This isn't a bug per se, but I can file one if requested.
>>
>> https://go2goplay.golang.org/p/AWynhg6ya7h
>>
>> Since embedding interfaces with type lists uses the intersection of
>> the items in the type list, it's possible to create an interface that
>> cannot be satisfied by any type.
>>
>> Currently this does not cause an error until you attempt to
>> instantiate something that uses such an interface as a bound.
>>
>> I think it would be more useful to raise the error when defining the
>> interface that cannot be used as it's likely an error—or at least I
>> can see no valid use for creating an unsatisfiable constraint.
>>
>> --
>> 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
>> https://groups.google.com/d/msgid/golang-nuts/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%40mail.gmail.com
>> .
>>
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com
> 
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEiwoyZQZuq3w3wwJrj1z3rZe8Hb7ed7v1yohisbYMAvA%40mail.gmail.com.

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

[David Riley]

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 should be thought of 
> just like other parameters in a function call.

This is precisely why I don't like it, because they are *metaparameters*. 
Having a variable length set of options where the length determines what the 
FIRST options are is actually really confusing, particularly because we already 
have an optional set of parentheses for the return types.

I understand that folks familiar with Lisp/Scheme might be comfortable with it, 
but I'm very comfortable with both of those and I find this a bit maddening.  
Could be just me.

I really do like the idea of separate characters for metaparameters on 
functions; another option would be Python/Java style decorators on the function 
(e.g. @type(A)), though I think in practice that might be a bit unpleasant (I 
really wish there were a better way to do the decorator pattern in Go, though). 
 I'm somewhat surprised that the parser developers find the variable-length 
list of parenthetical clauses *easier* to deal with; it seems like a good way 
to introduce ambiguity in the parsing.  That may be part of why the parser 
currently breaks when returning closures.  But then, I'm not the one writing 
the parser, so I'm running on a lot of assumptions.

I'm all for giving this time to settle and see how it plays out, of course.  
One thing I've learned is that it's generally a fool's errand to optimize for 
my use cases, at least if anyone else is going to like it.  But consider this 
my vote for alternate delimiters.


- Dave

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/D495EE84-B30E-46BD-9DD7-3E4531DFCB18%40gmail.com.


signature.asc
Description: Message signed with OpenPGP

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

['Bryan C. Mills' via golang-nuts]

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 instantiation in the return type: 
> https://go2goplay.golang.org/p/gcD609dr21E
>
> 
>
> type Foo(type T) struct {}
>
> type FooFunc(type T) func() Foo(T)
>
> func bar(type T)() FooFunc(T) {
> return func() Foo(T) {
> return Foo(T){}
> }
> }
>
> 
>
> Looks like someone else just posted that naming the return value is a 
> workaround for this parser issue: 
> https://go2goplay.golang.org/p/0Kdfj81Ot3B
>
> 
>
> type Foo(type T) struct {}
>
> type FooFunc(type T) func() Foo(T)
>
> func bar(type T)() FooFunc(T) {
> return func() (_ Foo(T)) {
> return Foo(T){}
> }
> }
>
> 
>
> > On Jun 18, 2020, at 2:17 PM, teiva...@gmail.com wrote:
> > 
> > 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 that would return a Foo(T)?
> > 
> > Here is the playground: https://go2goplay.golang.org/p/N-b10vSCois
> > 
> > Cheers
> > 
> > -- 
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/2083e7d6-95f4-4d34-b5c1-6f986d0d4c51o%40googlegroups.com
> .
>
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/c0c3a22a-2701-404a-b854-76a56e9e9d9bn%40googlegroups.com.

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

[David Riley]

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 FooFunc(type T) func() Foo(T)

func bar(type T)() FooFunc(T) {
return func() Foo(T) {
return Foo(T){}
}
}



Looks like someone else just posted that naming the return value is a 
workaround for this parser issue: https://go2goplay.golang.org/p/0Kdfj81Ot3B



type Foo(type T) struct {}

type FooFunc(type T) func() Foo(T)

func bar(type T)() FooFunc(T) {
return func() (_ Foo(T)) {
return Foo(T){}
}
}



> On Jun 18, 2020, at 2:17 PM, teivah@gmail.com wrote:
> 
> 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 that would return a Foo(T)?
> 
> Here is the playground: https://go2goplay.golang.org/p/N-b10vSCois
> 
> Cheers
> 
> -- 
> 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 
> https://groups.google.com/d/msgid/golang-nuts/2083e7d6-95f4-4d34-b5c1-6f986d0d4c51o%40googlegroups.com.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/9D3C56F5-713F-4177-82A0-27D012BA682B%40gmail.com.

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

['Bryan C. Mills' via golang-nuts]

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 preserve them.

I would recommend filing an issue per 
https://go.googlesource.com/go/+/refs/heads/dev.go2go/README.go2go.md.
On Thursday, June 18, 2020 at 2:18:48 PM UTC-4 teiva...@gmail.com wrote:

> 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 that would return a *Foo(T)*?
>
> Here is the playground: https://go2goplay.golang.org/p/N-b10vSCois
>
> Cheers
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/472dc188-3b01-40bb-a56c-8c22f2782cf3n%40googlegroups.com.

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

[Bebop Leaf]

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 considered as `(Foo T)`, which is named return.

This is mentioned partly at 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#using-generic-types-as-unnamed-function-parameter-types.
 
But I think at lease it should be updated to include return value 
declaration.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/e26bf937-74c3-4562-b1f4-a1ea34518943o%40googlegroups.com.

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

[Sam Mortimer]

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 
> > - Function parameters/arguments 
> > - Return tuple 
> [cut]
>
> Let's try the current suggested syntax and see how it works out in 
> practice. 
>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
>  
>
> Ian 
>

I agree with others that multiple () blocks on the same line is hard to 
read (so far, at least).  In general, I think parser complexity should come 
second to the cognitive complexity of humans reading code.  Any other means 
of separating type parameters in a more visually distinctive way would seem 
preferable.

Regards,
-Sam.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/7a576cef-cca5-433c-ae79-196b895212d5o%40googlegroups.com.

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

[lgodio2]

"  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 Thursday, June 18, 2020 at 12:31:04 PM UTC-4, Thomas Bushnell, BSG 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 should be thought 
> of just like other parameters in a function call. 
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/03188960-2939-477e-a5ec-66c11f2fa9beo%40googlegroups.com.

[go-nuts] [generics] Closure?

[teivah . dev]

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 that would return a *Foo(T)*?

Here is the playground: https://go2goplay.golang.org/p/N-b10vSCois

Cheers

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/2083e7d6-95f4-4d34-b5c1-6f986d0d4c51o%40googlegroups.com.

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

[Jesper Louis Andersen]

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
treatment. That a parameter varies by type rather than term is just a small
curio.. See the lambda cube.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiXpfgFF_7uQ7kFTBc0%2BwuNXZdFzW2ELAEEbUM%3DHy2Keow%40mail.gmail.com.

[go-nuts] [generics] Feedback

[ivanivanyuk1993]

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 messages useful?

This generic code makes sense more than code duplication; define feels like 
Go, if it means is it comfortable to read and write - yes it is; _; _;

2) Second, we know that many people have said that Go needs generics, but 
we don’t necessarily know exactly what that means. Does this draft design 
address the problem in a useful way? If there is a problem that makes you 
think “I could solve this if Go had generics,” can you solve the problem 
when using this tool?

This draft design definitely helps to address the problem in a useful way. 
A tool is a first step to write libraries, which can benefit from generics, 
in go, like flutter, fuchsia, generic caches, collections, data structures, 
rxGo, etc.

Suggestions for further improvements, from more beneficial to less
1) Add generic libraries to work with collections (like LINQ) and 
streams(rxGo), generic data structures to standard library
2) Improve type inference
3) Add client-side go libraries, like Angular-go, or Flutter-go

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/cd2b67da-96dc-4182-9c70-88e15ff32545o%40googlegroups.com.

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

[teivah]

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 2:37 PM Harald Weidner  > wrote: 
> > 
> > > Here is the playground: https://go2goplay.golang.org/p/CVvUuNJVX-M 
> > > I am unable to make this example to compile. 
> > 
> > This one compiles: 
> > https://go2goplay.golang.org/p/2rmaCymukdv 
>
> Thanks.  I'm not sure why those parentheses are needed.  Filed 
> https://golang.org/issue/39670 to either fix the parser or update the 
> design draft. 
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6ede54c6-bd30-40b1-8027-6e25d21c0637o%40googlegroups.com.

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

[naren . yellavula]

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])))
b.WriteString(str[1:])

return b.String()

}

func main() {
var str string = "GoLang"
fmt.Println(ToLowerCase(str))
}



Playground here: https://play.golang.org/p/aAyBGnM5p2x

On Saturday, 24 November 2012 11:51:23 UTC+1, Nikolai wrote:
>
> Hi!
>
> What is the easiest way to make a string "LikeThis" --> "likeThis"?
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/59ede7f8-bfb9-44a0-9fa7-cef1d7288983o%40googlegroups.com.

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

[Brian Zhao]

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 proposed workaround was:

We're going to try a variant of #1, using a variation of the disambiguation
> rule used in C#. Essentially, when we see:
> identifier <
> we look ahead, trying to parse a type parameter list, until parsing the
> type parameter list fails or we find a closing '>'. We then look ahead an
> additional token to see if the closing '>' is followed by a '(', '.', or
> closing bracketing token (since types are most commonly followed by a
> constructor call or static member access). If parsing the type parameter
> list succeeds, and the closing angle bracket is followed by a '(', '.', or
> closing bracket token, then the '<...>' sequence is parsed as a generic
> parameter list; otherwise, the '<' is parsed as an operator.


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#).

Thanks!

On Wed, Jun 17, 2020 at 5:50 PM 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
> > - Function parameters/arguments
> > - Return tuple
> >
> > This results in code like (from the draft):
> > func Stringify(type T Stringer)(s []T) (ret []string) {
> >   for _, v := range s {
> > ret = append(ret, v.String())
> >   }
> >   return ret
> > }
> >
> > Instead, using <> similar to other languages, makes it easier to visual
> parse:
> > func Stringify(s []T) (ret []string) {
> >   for _, v := range s {
> > ret = append(ret, v.String())
> >   }
> >   return ret
> > }
> >
> > This can also apply to type definitions:
> > type Vector []T
> >
> > To summarize:
> > - Having 3 times () in a row makes it confusing to visual parse
> > - The type keyword is not necessary
> > - Using <> would make it friendly (and easier to recognize)
>
> Let's try the current suggested syntax and see how it works out in
> practice.
>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java
>
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU%2B8XFLa7LU1Eaq_bYziAdBLxnR_WG19LLfcoN4qMh-ew%40mail.gmail.com
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CABrbJR6xB%3DhaQ%2BFHX28QyhKQwrHBnJqRnZ6Mb6xma%3D3_XAbVKA%40mail.gmail.com.

[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 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 
https://groups.google.com/d/msgid/golang-nuts/CANwLzMsiqicAHzzUET3BvSUYwbB69LTqXu0%3Dt0uQcdcfzHUd1g%40mail.gmail.com.

[go-nuts] [generics] Zero value

[brunokim . mc]

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 
,
 
so I'd like to use this topic just to provide my sentiment, and perhaps 
gather it from others.

In my opinion, the most Go-like proposal 
 is using '_' to signify the 
zero value in RHS. We are already used to having '_' in LHS to accept 
whatever type, and although the meaning is slightly changed (from 
'whatever' to 'zero'), it's conceptually close.

I'm opposed to a change that uses '{}' or 'T{}' to mean zero type, as in 
this proposal , because in my 
mind curly braces are used for composite types. Imagining that 'T' is a 
placeholder, It's weird replacing 'T{}' for 'int{}', for example. I'm super 
in favor of having a leaner syntax for composite types, though 😁.

Whatever is decided, please don't punt on this issue and recommend 
'*new(T)'. That's really ugly and feels wrong to allocate and immediately 
dereference the value just to circumvent a syntax change. Even if the 
compiler is smart enough not to allocate anything, that's what's written in 
the source code.

Thanks.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/a061b28e-3872-4c47-97ad-a3651f8a8b2bo%40googlegroups.com.

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

[Tobias Weingartner]

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 option to move these to something like:

```
typedef FuncName(T1, T2 Stringer)
func FuncName(a T1, b T2) (T1, error) {
  // ...
}
```

Note, INALL (I'm not a language lawyer)...

-Toby.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CA%2BfYmx1M9mHhbzk04eoKSSFYzGGX60m46NUwoxrBA4ooVFUpmg%40mail.gmail.com.

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

['Thomas Bushnell, BSG' via golang-nuts]

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 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 
https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxse-3Y1J201bTDS%3DGq33bqKKzdJ4AHABrqM5PDgrLwKcg%40mail.gmail.com.

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

[Bebop Leaf]

> 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.

> also for lines 18 and 22 if the type is not primitive type (another 
identifier), feels like a function that returns a function

I actually like this kind of feeling. It actually is almost what happening 
- you can consider it as a function returning a function most of the time 
(the only time I can think of that you care about the difference is you 
want to optimize out the function call), but when you really care about the 
difference, you can quickly find out that by noticing float is actually a 
type.

Consider this snippet of code, from the example code in standard library 
`sort` (SortKeys):

By(name).Sort(planets)
fmt.Println("By name:", planets)

By(mass).Sort(planets)
fmt.Println("By mass:", planets)

By(distance).Sort(planets)
fmt.Println("By distance:", planets)

Here, `By` is actually a type of function - and the seemingly function call 
`By(...)` is actually a type conversion, not a function returning something 
with a `Sort` method.  But I won't say this cause much confusion. I think 
the use of the proposed generic function works in the same way.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/831b-f554-42ec-ae6b-4e22a1213d29o%40googlegroups.com.

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

[T L]

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 which converting a slice with type 
 Ta to a slice with type Tb. Like 
 func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...}


  
>> For example, I need a ConvertSlice function which will do
>> * Convert []int to []int64, and the inverse
>> * Convert string to []byte, and the inverse
>> * Convert between several struct types with the same field set, except 
>> their field tags are different.
>> * more generally, Convert []Ta to []Tb, and the inverse, where Ta can be 
>> converted to Tb.
>>
>
> None of these are interface types. I think I don't understand your 
> question. Was there a typo and you meant "integer"? In that case, the 
> answer is here:
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-constraints
> You mention four very different use cases. I don't understand how to unify 
> them into one question.
>
>
>>  
>>
>>> How to constraint a type parameter must be of an interface type?

>>>
>>> I don't think you can. Why would you need to? Note that there will 
>>> always be constraints that you can't express.
>>>
>>
>> One need is the same as the above Convert case, there should be more. 
>>
>> func ConvertSlice(type T, I constraint)(ins []T) []I {...} 
>>
>> Where I must/may be some special interface types.
>>
>
> You still haven't said *why* you need it to be an interface type. What 
> does knowing it's an interface allow you to do? Why would it break if 
> someone passed a concrete type?
>
>
>
>>
>>>
 Is it possible to define generic unnamed types?

>>>
>>> No. It also would be useless. You can't refer to a generic, 
>>> uninstantiated type. So a generic type either needs a name to be referred 
>>> by to instantiate it, or be instantiated right immediately in its 
>>> declaration (and thus wouldn't need to be generic).
>>>
>>> If it is impossible, then how to define a generic map type which 
 elements must be an unnamed integer slice?

>>>
>>> type numeric interface {
>>> type int, int8, int16, int32, ...
>>> }
>>>
>>> type MyMap(type K comparable, T numeric) map[K][]T
>>>
>>
>> Sorry, here I meant "... must be of a slice with an unnamed element type".
>>
>
> I don't think that's possible. And the same question as above applies: Why 
> is that an important constraint to be able to express?
>
> I'm sorry, but I just don't understand what you are trying to ask.
>
> Sometimes, the map element slice type itself might be required to be shown 
>> as a type parameter.
>>
> One of the case is still related to slice conversions.
>>  
>>
>
It is a little hard to describe it clearly. I will continue this question 
when I sort it out.
 

>
>>> -- 
 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 golan...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com
  
 
 .

>>>
>>
>>  
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/0ef1456d-8d8c-4d74-a36a-82e2b3337765o%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/cedd7b44-0cb1-4a60-9cbd-2f40718d3526o%40googlegroups.com.

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

[T L]

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) {} // undefined: MyInt 
> > 
> > func main() { 
> > type MyInt int 
> > Foo([]MyInt(nil)) 
> > } 
>
> It compiles if you move "type MyInt int" out of the func main scope. See 
> https://go2goplay.golang.org/p/_sWi72-0rD1 
>
> Harald 
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/937ace02-47b4-473b-8fc6-1107e1192d74o%40googlegroups.com.

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

[T L]

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 which converting a slice with type 
 Ta to a slice with type Tb. Like 
 func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...}


  
>> For example, I need a ConvertSlice function which will do
>> * Convert []int to []int64, and the inverse
>> * Convert string to []byte, and the inverse
>> * Convert between several struct types with the same field set, except 
>> their field tags are different.
>> * more generally, Convert []Ta to []Tb, and the inverse, where Ta can be 
>> converted to Tb.
>>
>
> None of these are interface types. I think I don't understand your 
> question. Was there a typo and you meant "integer"? In that case, the 
> answer is here:
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-constraints
> You mention four very different use cases. I don't understand how to unify 
> them into one question.
>
>
>>  
>>
>>> How to constraint a type parameter must be of an interface type?

>>>
>>> I don't think you can. Why would you need to? Note that there will 
>>> always be constraints that you can't express.
>>>
>>
>> One need is the same as the above Convert case, there should be more. 
>>
>> func ConvertSlice(type T, I constraint)(ins []T) []I {...} 
>>
>> Where I must/may be some special interface types.
>>
>
> You still haven't said *why* you need it to be an interface type. What 
> does knowing it's an interface allow you to do? Why would it break if 
> someone passed a concrete type?
>

For examples, I want to convert a []int value "vs" to a []interface{} value 
so that it can be passed to the fmt.Println(Convert(int, 
interface{})(vs)...).
But I don't need a Convert generic function which can convert []int to 
[]interface{} specifically.
What I need is a common generic function which can convert []Ta value to 
[]Tb if Ta values can be converted to Tb.

That means, the above two questions are the same question.
 

>
>
>
>>
>>>
 Is it possible to define generic unnamed types?

>>>
>>> No. It also would be useless. You can't refer to a generic, 
>>> uninstantiated type. So a generic type either needs a name to be referred 
>>> by to instantiate it, or be instantiated right immediately in its 
>>> declaration (and thus wouldn't need to be generic).
>>>
>>> If it is impossible, then how to define a generic map type which 
 elements must be an unnamed integer slice?

>>>
>>> type numeric interface {
>>> type int, int8, int16, int32, ...
>>> }
>>>
>>> type MyMap(type K comparable, T numeric) map[K][]T
>>>
>>
>> Sorry, here I meant "... must be of a slice with an unnamed element type".
>>
>
> I don't think that's possible. And the same question as above applies: Why 
> is that an important constraint to be able to express?
>
> I'm sorry, but I just don't understand what you are trying to ask.
>
> Sometimes, the map element slice type itself might be required to be shown 
>> as a type parameter.
>>
> One of the case is still related to slice conversions.
>>  
>>
>>>
>>> -- 
 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 golan...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com
  
 
 .

>>>
>>
>>  
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/0ef1456d-8d8c-4d74-a36a-82e2b3337765o%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/2eaf16fc-6931-45b4-977f-750a1a48dd87o%40googlegroups.com.

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

[Jesper Louis Andersen]

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 compile time restrictions.

On Wed, Jun 17, 2020, 22:09 jimmy frasche  wrote:

> This isn't a bug per se, but I can file one if requested.
>
> https://go2goplay.golang.org/p/AWynhg6ya7h
>
> Since embedding interfaces with type lists uses the intersection of
> the items in the type list, it's possible to create an interface that
> cannot be satisfied by any type.
>
> Currently this does not cause an error until you attempt to
> instantiate something that uses such an interface as a bound.
>
> I think it would be more useful to raise the error when defining the
> interface that cannot be used as it's likely an error—or at least I
> can see no valid use for creating an unsatisfiable constraint.
>
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/CANG3jXJt_n1HrRMV1SBcaurXOrXVJxXrKN_F%3DtgMAcMJ%2BPOLcg%40mail.gmail.com
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVPP21fky2qcgfnAYjH6H047C1A0Y_V%3Doa%3DB3pTWRX68g%40mail.gmail.com.

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

['Bryan C. Mills' via golang-nuts]

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 type-list would be meaningful: it would be 
an interface type whose only valid value is nil.

(In more formal terms, it would be the unique bottom element of the 
interface-type lattice, equivalent to the nil case in a type-switch today.)

On Wednesday, June 17, 2020 at 6:54:00 PM UTC-4 soapboxcicero wrote:

> The only case I mean is when the intersection of the type lists is ∅. 
> That's easy to check and always wrong afaict. 
>
> On Wed, Jun 17, 2020 at 3:47 PM Ian Lance Taylor  
> wrote: 
> > 
> > On Wed, Jun 17, 2020 at 1:09 PM jimmy frasche  
> wrote: 
> > > 
> > > This isn't a bug per se, but I can file one if requested. 
> > > 
> > > https://go2goplay.golang.org/p/AWynhg6ya7h 
> > > 
> > > Since embedding interfaces with type lists uses the intersection of 
> > > the items in the type list, it's possible to create an interface that 
> > > cannot be satisfied by any type. 
> > > 
> > > Currently this does not cause an error until you attempt to 
> > > instantiate something that uses such an interface as a bound. 
> > > 
> > > I think it would be more useful to raise the error when defining the 
> > > interface that cannot be used as it's likely an error—or at least I 
> > > can see no valid use for creating an unsatisfiable constraint. 
> > 
> > In order to ensure that all Go compilers act the same, we would have 
> > to very carefully define the cases that are not accepted. This is a 
> > little harder than it sounds since matching is done on underlying 
> > types. At least for now I tend to think that it would be better to 
> > make this a vet check. But I don't feel all that strongly about it. 
> > 
> > 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/11a2ccef-f8e5-4de6-9374-c2f72e309b4fn%40googlegroups.com.

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

['Bryan C. Mills' via golang-nuts]

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. Like 
>>> func ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...}
>>>
>>>
>>>  
> For example, I need a ConvertSlice function which will do
> * Convert []int to []int64, and the inverse
> * Convert string to []byte, and the inverse
> * Convert between several struct types with the same field set, except 
> their field tags are different.
> * more generally, Convert []Ta to []Tb, and the inverse, where Ta can be 
> converted to Tb.
>

I attempted to write a similar function using assignability rather than 
conversion.¹
Neither constraint is possible in the current draft.
(See 
https://golang.org/design/go2draft-type-parameters#no-way-to-express-convertability.)

However, I believe that it would be possible (and coherent with the design) 
to add built-in interface types for “assignable to T” and “convertible to 
T” (but not “assignable from T” or “convertible from T”).
(https://github.com/bcmills/go2go/blob/master/assignable.md contains more 
detail.)

¹ My use-cases are the same as those described in:
https://golang.org/doc/faq#convert_slice_of_interface
https://golang.org/doc/faq#convert_slice_with_same_underlying_type
https://golang.org/issue/38753
https://golang.org/issue/38385, esp. 
https://github.com/golang/go/issues/38385#issuecomment-612668321
https://golang.org/issue/21651
https://golang.org/issue/3756

How to constraint a type parameter must be of an interface type?
>>>
>>
>> I don't think you can. Why would you need to? Note that there will always 
>> be constraints that you can't express.
>>
>
> One need is the same as the above Convert case, there should be more. 
>
> func ConvertSlice(type T, I constraint)(ins []T) []I {...} 
>
> Where I must/may be some special interface types.
>
>
>>
>>> Is it possible to define generic unnamed types?
>>>
>>
>> No. It also would be useless. You can't refer to a generic, 
>> uninstantiated type. So a generic type either needs a name to be referred 
>> by to instantiate it, or be instantiated right immediately in its 
>> declaration (and thus wouldn't need to be generic).
>>
>> If it is impossible, then how to define a generic map type which elements 
>>> must be an unnamed integer slice?
>>>
>>
>> type numeric interface {
>> type int, int8, int16, int32, ...
>> }
>>
>> type MyMap(type K comparable, T numeric) map[K][]T
>>
>
> Sorry, here I meant "... must be of a slice with an unnamed element type".
> Sometimes, the map element slice type itself might be required to be shown 
> as a type parameter.
> One of the case is still related to slice conversions.
>  
>
>>
>> -- 
>>> 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 golan...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/0ce2c4f4-9abc-405d-9117-749ab426f2d3n%40googlegroups.com.

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

[Bebop Leaf]

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 returns a function.
It would be the way generic function work, if types are data in Go, imo.

BTW, I think the fact that the new parentheses are never nested into other 
use of parentheses makes reading them much less confusing than supposed, 
but maybe that is just for me.

And disclaimer: I do write common lisp codes as side hobbies, so take this 
with a grain of salt - I might developed some kind of adaption to 
parentheses that I am not aware of.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/0c10b780-0ebc-4467-97a3-c3603aaa9bf1o%40googlegroups.com.

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

[Kiswono Prayogo]

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 the web visit 
https://groups.google.com/d/msgid/golang-nuts/757fac35-9eab-4b38-8514-94cf7d7de330o%40googlegroups.com.

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

[Miguel Angel Rivera Notararigo]

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 well as readable, so if you could convert []Foo to
> []Stringer you'd also have to say what happens when you assign a
> *different* Stringer to an element of it - and the only thing that could
> happen is a panic.
>
> The memory-layout explanation never rang true to me. After all, we *do*
> allow converting between string and []rune, which has the same problem.
>
> On Thu, Jun 18, 2020, 04:53 Miguel Angel Rivera Notararigo <
> ntr...@gmail.com> wrote:
>
>> Oh, it was a FAQ haha sorry about that and thanks Tyler and Ian :D
>>
>> --
>> 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
>> https://groups.google.com/d/msgid/golang-nuts/CAF9DLC%3DuAUJ3R8%3Dt%3DakiAiG-JPaxvkju7T%3DeU9saEirbOy8Z%3DA%40mail.gmail.com
>> 
>> .
>>
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAF9DLCm7yJng_oFgsyYYt3GpTMgsXN4TPJgnHnb7x-nE618qJw%40mail.gmail.com.

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

[Kiswono Prayogo]

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, parameter, return value, function 
calls, grouping, etc).


Current https://go2goplay.golang.org/p/zBO9K4-yXck


package main

import (
"fmt"
)

type Stack(type T) struct {
list []T
}
type Pair(type K, V) struct {
Key K
Val V
}

func New(type T)() Stack(T) {
return Stack(T){list: []T{}}
}
func (s *Stack(T)) Push(v T) {
s.list = append(s.list, v)
}
func main() {
a := New(int)()
fmt.Printf("%#v\n",a)
b := Stack(Stack(int)){}
fmt.Printf("%#v\n",b)
c := Pair(string,int){}
fmt.Printf("%#v\n",c)
}


Probably more readable syntax:

   - F:T for single generic declaration and usage, eg. Stack:int, 
   BinaryTree:string, Vector:Person
   - F:[T1,T2] for multiple generic declaration and usage or when having 
   constraint or array/slice, eg. Pair:[string,int], HashTable:[string,int], 
   Stack:[T Stringer], Stack:[[3]int]
   - F:[T1:T2] for nested generic usage, eg. Stack:[Queue:int]

So for example, if we want to use Stack that stores string-int Pair, we 
could use: Stack:[Pair:[string,int]], if we want to use Pair with string 
key and integer Stack value, we could use: Pair:[string,Stack:int]

The pros:

   - we could always differentiate between function calls (that returns 
   function) and generics by : or :[] symbol, other than just checking 
   whether passed parameter is a datatype or variable/constant identifier. = 
   unambiguous
   - consistent syntax between generic declaration and usage

type Stack:T struct {
list []T
}
type Pair:[K,V] struct {
Key K
Val V
}

func New:T() Stack:T {
return Stack:T{list: []T{}}
}
func (s *Stack:T) Push(v T) {
s.list = append(s.list, v)
}
func main() {
a := New:int()
fmt.Prinf("%#v\n",a)
b := Stack:[Stack:int]{}
fmt.Printf("%#v\n",b)
c := Pair:[string,int]{}
fmt.Printf("%#v\n",c)
}

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/d0cd52bc-b33d-4256-83e3-40a0a24ddc3do%40googlegroups.com.

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

[Harald Weidner]

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 func main scope. See
https://go2goplay.golang.org/p/_sWi72-0rD1

Harald

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/20200618121650.GA16023%40hweidner.de.

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

['Axel Wagner' via golang-nuts]

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 ConvertSlice(type Ta, Tb constraint)(ins []Ta) []Tb {...}
>>>
>>>
>>>
> For example, I need a ConvertSlice function which will do
> * Convert []int to []int64, and the inverse
> * Convert string to []byte, and the inverse
> * Convert between several struct types with the same field set, except
> their field tags are different.
> * more generally, Convert []Ta to []Tb, and the inverse, where Ta can be
> converted to Tb.
>

None of these are interface types. I think I don't understand your
question. Was there a typo and you meant "integer"? In that case, the
answer is here:
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-constraints
You mention four very different use cases. I don't understand how to unify
them into one question.


>
>
>> How to constraint a type parameter must be of an interface type?
>>>
>>
>> I don't think you can. Why would you need to? Note that there will always
>> be constraints that you can't express.
>>
>
> One need is the same as the above Convert case, there should be more.
>
> func ConvertSlice(type T, I constraint)(ins []T) []I {...}
>
> Where I must/may be some special interface types.
>

You still haven't said *why* you need it to be an interface type. What does
knowing it's an interface allow you to do? Why would it break if someone
passed a concrete type?



>
>>
>>> Is it possible to define generic unnamed types?
>>>
>>
>> No. It also would be useless. You can't refer to a generic,
>> uninstantiated type. So a generic type either needs a name to be referred
>> by to instantiate it, or be instantiated right immediately in its
>> declaration (and thus wouldn't need to be generic).
>>
>> If it is impossible, then how to define a generic map type which elements
>>> must be an unnamed integer slice?
>>>
>>
>> type numeric interface {
>> type int, int8, int16, int32, ...
>> }
>>
>> type MyMap(type K comparable, T numeric) map[K][]T
>>
>
> Sorry, here I meant "... must be of a slice with an unnamed element type".
>

I don't think that's possible. And the same question as above applies: Why
is that an important constraint to be able to express?

I'm sorry, but I just don't understand what you are trying to ask.

Sometimes, the map element slice type itself might be required to be shown
> as a type parameter.
>
One of the case is still related to slice conversions.
>
>
>>
>> --
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com
>>> 
>>> .
>>>
>>
>
>
>
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/0ef1456d-8d8c-4d74-a36a-82e2b3337765o%40googlegroups.com
> 
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGnB3-5E6LHoSm7_O9Li8g5Kdv1J6d9kwOo72R%2BaFRhbA%40mail.gmail.com.

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

[T L]

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 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
> Foo([]MyInt(nil))
> }
>
> On Thursday, June 18, 2020 at 7:22:51 AM UTC-4, T L wrote:
>>
>> 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)
>> }
>>
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/cfa7f3a8-fda2-493f-856a-75908330181do%40googlegroups.com.

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

[T L]

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
Foo([]MyInt(nil))
}

On Thursday, June 18, 2020 at 7:22:51 AM UTC-4, T L wrote:
>
> 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)
> }
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/c5f5f3b8-b609-4795-9f27-806409decd5ao%40googlegroups.com.

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

[Volker Dobler]

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 using <> is that lots of languages with parametric 
polymorphism do not use <>. It makes learning just easier for new Go 
developers that have experience with such languages.

I dislike the use of () but a) this discussion can be made once the overall 
mechanism of generics / pp is settled and b) it really doesn't matter that 
much and c) it probably won't be plain <> anyway if its not () so endless 
repetitions of "<> please" is just a waste of time.

V.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/18ef1573-8b32-4fca-bd2d-62ae9b2e634bo%40googlegroups.com.

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

[T L]

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)
}

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/325771a1-bc75-425f-9d25-9f768bba175bo%40googlegroups.com.

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

[T L]

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 {...}
>>
>>
>>  
For example, I need a ConvertSlice function which will do
* Convert []int to []int64, and the inverse
* Convert string to []byte, and the inverse
* Convert between several struct types with the same field set, except 
their field tags are different.
* more generally, Convert []Ta to []Tb, and the inverse, where Ta can be 
converted to Tb.

 

> How to constraint a type parameter must be of an interface type?
>>
>
> I don't think you can. Why would you need to? Note that there will always 
> be constraints that you can't express.
>

One need is the same as the above Convert case, there should be more. 

func ConvertSlice(type T, I constraint)(ins []T) []I {...} 

Where I must/may be some special interface types.


>
>> Is it possible to define generic unnamed types?
>>
>
> No. It also would be useless. You can't refer to a generic, uninstantiated 
> type. So a generic type either needs a name to be referred by to 
> instantiate it, or be instantiated right immediately in its declaration 
> (and thus wouldn't need to be generic).
>
> If it is impossible, then how to define a generic map type which elements 
>> must be an unnamed integer slice?
>>
>
> type numeric interface {
> type int, int8, int16, int32, ...
> }
>
> type MyMap(type K comparable, T numeric) map[K][]T
>

Sorry, here I meant "... must be of a slice with an unnamed element type".
Sometimes, the map element slice type itself might be required to be shown 
as a type parameter.
One of the case is still related to slice conversions.
 

>
> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com
>>  
>> 
>> .
>>
>

 

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/0ef1456d-8d8c-4d74-a36a-82e2b3337765o%40googlegroups.com.

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

['Axel Wagner' via golang-nuts]

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 you can. Why would you need to? Note that there will always
be constraints that you can't express.


> Is it possible to define generic unnamed types?
>

No. It also would be useless. You can't refer to a generic, uninstantiated
type. So a generic type either needs a name to be referred by to
instantiate it, or be instantiated right immediately in its declaration
(and thus wouldn't need to be generic).

If it is impossible, then how to define a generic map type which elements
> must be an unnamed integer slice?
>

type numeric interface {
type int, int8, int16, int32, ...
}

type MyMap(type K comparable, T numeric) map[K][]T

-- 
> 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
> https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com
> 
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFHFe_RogeoG8Qq_RF4zA-2f%2Bt-W60ZdLQXX01Sh1rW6g%40mail.gmail.com.

[go-nuts] [generics] some questions

[T L]

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 impossible, then how to define a generic map type which elements 
must be an unnamed integer slice?

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/f02971c4-7e16-4f33-b919-93e7569d6571o%40googlegroups.com.

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

[Hal]

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 declarations)
>
> On Wednesday, June 17, 2020 at 5:50:47 AM UTC-6, Brian Candler wrote:
>>
>> Consider a generic where you want T1 unconstrained but T2 constrained.  
>> If you write
>>
>> func Foo(type T1, T2 Bar)
>>
>> then Bar constrains both.  Hence the need for
>>
>> func Foo(type T1 interface{}, T2 Bar)
>>
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/ad8aee78-8e12-4dcf-8067-60062e782102o%40googlegroups.com.

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

[Florin Pățan]

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 functions. Previously, in some cases, the 
compiler allowed multiple chained conversions (for example, 
syscall.Syscall(…, uintptr(uintptr(ptr)), …)). The compiler now requires 
exactly one conversion. Code that used multiple conversions should be 
updated to satisfy the safety rules. 

After reading that paragraph, I expect that the compiler fails to compile 
code after that change. When running `go build` or `go build 
-gcflags="-d=checkptr"` neither produce a failure. I used `go vet`, and 
that doesn't catch this change either.

The example I used is https://play.golang.org/p/a0B4kxLEAjb.

Perhaps I failed to construct a correct example, in which case help would 
be appreciated.

I was not sure if this belongs to the mailing list or the issue tracker, so 
I started here.

Thank you.

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/48f7e966-80d9-4d47-9932-1fbd5d5476adn%40googlegroups.com.

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

[Nathanael Curin]

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 makes sense.

Le mercredi 17 juin 2020 18:36:10 UTC+2, Charles Crete a écrit :
>
> Based on the new proposal, having the type parameters as () seems very 
> confusing, as now 3 things in a row use ():
> - Type parameters
> - Function parameters/arguments
> - Return tuple
>
> This results in code like (from the draft):
> func Stringify(type T Stringer)(s []T) (ret []string) {
>   for _, v := range s {
> ret = append(ret, v.String())
>   }
>   return ret
> }
>
> Instead, using <> similar to other languages, makes it easier to visual 
> parse:
> func Stringify(s []T) (ret []string) {
>   for _, v := range s {
> ret = append(ret, v.String())
>   }
>   return ret
> }
>
> This can also apply to type definitions:
> type Vector []T
>
> To summarize:
> - Having 3 times () in a row makes it confusing to visual parse
> - The type keyword is not necessary
> - Using <> would make it friendly (and easier to recognize)
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/c524fc34-6d4a-4ae3-8db9-665f48c7b866o%40googlegroups.com.

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

['Axel Wagner' via golang-nuts]

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 when you assign a
*different* Stringer to an element of it - and the only thing that could
happen is a panic.

The memory-layout explanation never rang true to me. After all, we *do*
allow converting between string and []rune, which has the same problem.

On Thu, Jun 18, 2020, 04:53 Miguel Angel Rivera Notararigo 
wrote:

> Oh, it was a FAQ haha sorry about that and thanks Tyler and Ian :D
>
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/CAF9DLC%3DuAUJ3R8%3Dt%3DakiAiG-JPaxvkju7T%3DeU9saEirbOy8Z%3DA%40mail.gmail.com
> 
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFHH_g_VUckz%3DFLy0zvC-XkOBfq%2BfidWXQYsp2Se_aqLg%40mail.gmail.com.

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

[Gert]

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 specific problem as soon 
as consensus is reached by introducing a `go vet -generic` flag that does 
nothing more then just highlight this specific very rare problem. And 
introduce this small language change now so it's more than a year in 
advance in place.

The concern I think will come forward is when we don't give it a high 
enough priority early enough it will significantly handicap the generic 
error compiler messages if we don't be concrete about it?

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/f396c1dc-1766-452f-8fc8-aaa09c42ba6cn%40googlegroups.com.

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

[roger peppe]

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 Cheremisov 
wrote:

> Better example. A method to request for exacly one element from the gRPC
> bistream. A thing that is frequently needed when there're lots of bistream
> gRPC methods.
>
> https://go2goplay.golang.org/p/RQEyhRRQb0p
>
> IRL I would need to call it as
>
> resp, err := proto.ReadOne(service.Service_MethodClient,
> service.MethodRequest, service.MethodResponse)(ctx, client.Method,
> &service.MethodRequest{
> …
> })
>
> instead of simple to read
>
> resp, err := proto.ReadOne(ctx, client.Method, &service.MethodRequest{
> …
> })
>
> среда, 17 июня 2020 г., 19:43:35 UTC+3 пользователь Denis Cheremisov
> написал:
>>
>> https://go2goplay.golang.org/p/ObL79WVHDjw
>>
>> Need to write types explicitly although all the info needed is easily
>> accessible:
>>
>> fmt.Println(IsOK(*commonResponse, *commonError)(r))
>>
>> What I am sure is I will keep using a code generator instead of this
>> monstrosity.
>>
> --
> 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
> https://groups.google.com/d/msgid/golang-nuts/6bfdcc4c-dca8-4051-b89c-65274c2f6982o%40googlegroups.com
> 
> .
>

-- 
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 
https://groups.google.com/d/msgid/golang-nuts/CAJhgacj-5v%2BvTa0zx6xU1ir_ebJC8mnYQY7HYMU0YiLYtSevJA%40mail.gmail.com.