I could imagine a new kind of interface type specifying fields (not just
methods), with the offsets of the corresponding fields in the concrete type
stored in the interface's type descriptor.
(I think such a feature would be orthogonal to the current design draft,
and could be proposed
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
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
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
>
> It seems annoying to force
> everyone to write interface{} all the time when it is normally not
> needed.
>
I agree, omitting interface{} should not cause much trouble to the parser.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
Since Go will need to modify interface with new type list anyway. Is it
good if we can do this:
```
type Weighter interface {
Weight int
}
func CompareWeight(type T Weighter) (a, b T) bool {
return a.Weight < b.Weight
}
```
Instead of:
```
type Weighter interface {
GetWeight() int
On Jun 17, 2020, at 8:45 PM, Ian Lance Taylor wrote:
>
> On Wed, Jun 17, 2020 at 9:35 AM wrote:
>>
>> How do I write a function that can take any container? Either a built in
>> container or a user defined structure? Java is awkward when deciding to
>> accept arrays or the List type — is go
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,
On Wed, Jun 17, 2020 at 7:24 AM Konstantin Khomoutov wrote:
>
> On Wed, Jun 10, 2020 at 04:03:36PM -0700, Ian Lance Taylor wrote:
>
> [...]
> > In the current implementations of Go, Tickers are not garbage
> > collected. They run until they are stopped. So if you don't stop a
> > ticker, it
On Wed, Jun 17, 2020 at 4:19 AM Hal wrote:
>
> "If a constraint is specified for any type parameter, every type parameter
> must have a constraint. If some type parameters need a constraint and some do
> not, those that do not should have a constraint of interface{}."
>
> "interface{}" equals
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):
>
On Wed, Jun 17, 2020 at 9:35 AM hao luo wrote:
>
> The creator:
>
> Hi, I am extremely interested in and eager for golang's generics, and I have
> read the updated draft.
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#acknowledgements
>
> I think
On Wed, Jun 17, 2020 at 9:35 AM wrote:
>
> How do I write a function that can take any container? Either a built in
> container or a user defined structure? Java is awkward when deciding to
> accept arrays or the List type — is go fated to repeat this awkwardness?
It is as you fear: Go does
On Wed, Jun 17, 2020 at 9:35 AM tomas via golang-nuts
wrote:
>
> Could type parameters be omitted when they could be inferred in struct
> literals?
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference-for-composite-literals
Ian
--
You
On Wed, Jun 17, 2020 at 5:18 PM Randall O'Reilly wrote:
>
> Good point!
>
> I can think of 2 possible (non-mutex) solutions:
>
> * Use an explicit type expression to refer to the type: `type(ms.T)` and the
> field is just `ms.T`
>
> * Within the method scope, make `T` a valid type name, so you
Here's a proposal for a syntactic modification to the draft proposal that
removes explicit type parameters from functions, and just uses generic types
directly (e.g., the new interface types):
https://github.com/golang/go/issues/39669
This would go a long way toward simplifying the syntax and
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
Good point!
I can think of 2 possible (non-mutex) solutions:
* Use an explicit type expression to refer to the type: `type(ms.T)` and the
field is just `ms.T`
* Within the method scope, make `T` a valid type name, so you can just use `T`
directly -- this might even be preferable overall as it
On Wed, Jun 17, 2020 at 10:55 AM Tyler Compton wrote:
> The reason why implicit conversions from []Foo to []Stringer isn't
> supported is because Foo and Stringer have different in-memory
> representations. Converting from a slice of one to a slice of another would
> be more expensive than one
On Wednesday, 17 June 2020 07:54:02 UTC+10, Alexander Morozov wrote:
>
> I wonder how could we avoid this confusion (apart from using different
> brackets :)).
>
I know the brackets discussion has been had before, and that there are some
technical, and non-technical reasons why parentheses were
On Wed, Jun 17, 2020 at 4:40 PM envee wrote:
>
> Hi Robert, It is in my first post in this thread. Basically, I want to know
> why all my logical processors are not being used in my program. Thanks.
New goroutines are added to the run queue for the P that creates them.
When a P has nothing to
On Wed, Jun 17, 2020 at 4:33 PM jimmy frasche wrote:
>
> If I merge the two examples I still get an error
> https://go2goplay.golang.org/p/TNYLDLokGCQ
>
> prog.go2:21:2: int does not satisfy Z (int not found in ⊥)
I think that may be a bug in the type checker, which may not be quite
updated to
I think that second error is a bug. I would expect that case to be the
same as if I wrote a type list that was just int (and hence not the
empty type list).
On Wed, Jun 17, 2020 at 4:33 PM jimmy frasche wrote:
>
> If I merge the two examples I still get an error
>
Hi Robert, It is in my first post in this thread. Basically, I want to know
why all my logical processors are not being used in my program. Thanks.
On Thursday, 18 June 2020 07:24:40 UTC+10, Robert Engels wrote:
>
> What is the question?
>
> On Jun 17, 2020, at 4:06 PM, envee >
> wrote:
>
>
If I merge the two examples I still get an error
https://go2goplay.golang.org/p/TNYLDLokGCQ
prog.go2:21:2: int does not satisfy Z (int not found in ⊥)
On Wed, Jun 17, 2020 at 4:24 PM Ian Lance Taylor wrote:
>
> On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche wrote:
> >
> > The only case I mean
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
On Wed, Jun 17, 2020 at 3:52 PM jimmy frasche wrote:
>
> The only case I mean is when the intersection of the type lists is ∅.
> That's easy to check and always wrong afaict.
Unfortunately I don't think it's that simple.
type MyInt int
type I1 interface {
type int
}
type I2 interface {
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.
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
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
On Wednesday, June 17, 2020 at 2:00:00 PM UTC-7, Denis Cheremisov wrote:
>
> Another question about generics, a HOWTODO one: I am bored to death
> writing methods what would send one request and get one response from a
> gRPC bistream. Decided to try a draft 2 against a generic approach to the
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
Hello,
> 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
Regards,
Harald
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
What is the question?
> On Jun 17, 2020, at 4:06 PM, envee wrote:
>
> Hi, Is anyone able to help me here ?
> Here is a (simplified) snippet of the code, in case it helps answering my
> query. I basically create a goroutine for every input file (assume max 8) and
> then wait for processing of
Hi, Is anyone able to help me here ?
Here is a (simplified) snippet of the code, in case it helps answering my
query. I basically create a goroutine for every input file (assume max 8)
and then wait for processing of all files to finish. Each goroutine
processes a line within the file and then
Another question about generics, a HOWTODO one: I am bored to death writing
methods what would send one request and get one response from a gRPC
bistream. Decided to try a draft 2 against a generic approach to the task.
My final attempt which I still can't
compile:
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
On Wed, Jun 17, 2020 at 12:16 PM wrote:
>
> I remember using mainframe FORTRAN compilers where the compiler would print
> out a page of symbol cross references.
>
> For each symbol or function there would listed the line where it was defined
> and then line numbers where it was used/referenced.
Hello all,
I'm working on implementing generics on a big container projet.
So far, everything was good except for this very case:
type Foo(type T) struct {
v int
}
func (_ *Foo(T)) bar() int {
elem := <-make(chan Foo(T))
return elem.v
}
*Foo* being a generic structure, I have a
> if you find it more readable
not only readable. I still can't get why they banned constraints on structs
having some fields of certain type. With contracts they are easy to allow:
contract NameField(T) {
T Name string
}
and there's no hope with interfaces
ср, 17 июн. 2020 г. в 21:37,
I remember using mainframe FORTRAN compilers where the compiler would print
out a page of symbol cross references.
For each symbol or function there would listed the line where it was
defined and then line numbers where it was used/referenced.
Something similar would be useful for GO. Printing
oops, an infitie loop in the As implementation, now the right one:
https://go2goplay.golang.org/p/5NnZBnmIC96
среда, 17 июня 2020 г., 21:55:52 UTC+3 пользователь Denis Cheremisov
написал:
>
> There's an advantage though, for rather narrow cases though: reuse of
> interfaces:
>
>
There's an advantage though, for rather narrow cases though: reuse of
interfaces:
https://go2goplay.golang.org/p/HJr3QIzgQuX
среда, 17 июня 2020 г., 19:58:08 UTC+3 пользователь Denis Cheremisov
написал:
>
> IMO a groups of constraints are horrible with interfaces
>
> type CommonResponse(type
Ah sorry, I misunderstood. Please disregard :)
On Wed, Jun 17, 2020, 20:36 Axel Wagner
wrote:
> You can always combine multiple interface constraints:
>
> type ConstraintA(type A) interface {
> Foo() A
> }
>
> type ConstraintB(type B) interface {
> Bar() B
> }
>
> type
You can always combine multiple interface constraints:
type ConstraintA(type A) interface {
Foo() A
}
type ConstraintB(type B) interface {
Bar() B
}
type CombinedConstraint(type A, B) interface {
(ConstraintA(A))
(ConstraintB(B))
}
func F(type A, B CombinedConstraint(A, B))
I think this syntax could get confusing when embedded fields is added to
the mix:
type MyStruct(type T) struct {
T
}
func (ms *MyStruct) MyMethod(t ms.T) {
ms.T = t
}
In this example. ms.T means two very different things depending on where
they are used.
On Wed, Jun 17, 2020 at 3:45
The reason why implicit conversions from []Foo to []Stringer isn't
supported is because Foo and Stringer have different in-memory
representations. Converting from a slice of one to a slice of another would
be more expensive than one would expect an implicit conversion to be. At
least, this is my
Hello,
> There is an existing case which doesn't seem to bother many people:
>
> foo.Bar()
>
> Is this calling function Bar in package foo, or method Bar on variable
> foo?
It could also be a call of a function within the struct value foo.
foo.Bar(baz) can have at least four meanings:
1.
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.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving
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:
Thanks, can you maybe at the complete working code snippet in your issue too
```
type R(type T) struct{}
func F(type T)() {
_ = func() (_ R(T)) { return R(T){} }
}
```
I think it's not trivial code even after reading the issue what your
solution was to the problem.
--
You received this
more and more like Java..
BR
On Wed, Jun 17, 2020 at 11:36 PM 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
Better for who? You?
I would to love to see `[]` instead of `()`, but `<>` are horrible to read
IMO.
среда, 17 июня 2020 г., 19:36:09 UTC+3 пользователь hao luo написал:
>
> The creator:
>
> Hi, I am extremely interested in and eager for golang's generics, and I
> have read the updated draft.
This is not how it is typically done in Java. You create an immutable List that
is backed by the array. No copy required.
You will also implement RandonAccess to distinguish from linked lists.
Lastly, it doesn’t need to be immutable, and lots of structures like ArrayList
are mutable and
>
> makes it easier to visual parse
>
Are you sure? It may be a personal thing, but "visual parsing" of these <<<
really annoys me, I would prefer `[]`, but I like `()` more than `<>`. In
addition, a good IDE (not that well known overhyped editor on steroids)
will highlight these fragments, so
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
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 :=
How do I write a function that can take any container? Either a built in
container or a user defined structure? Java is awkward when deciding to accept
arrays or the List type — is go fated to repeat this awkwardness?
--
You received this message because you are subscribed to the Google Groups
The creator:
Hi, I am extremely interested in and eager for golang's generics, and I
have read the updated draft.
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#acknowledgements
I think use "<>" to declare template's type would be more appropriate.
At the end of this section where it shows the outputs:
```go
floats := slices.Map(s, func(i int) float64 { return float64(i) })// Now float2
is []float64{1.0, 2.0, 3.0}.
```
shouldn't that be:
```go
floats := slices.Map(s, func(i int) float64 { return float64(i) })// Now floats
is
Could you please explain what the problem was?
On Saturday, June 15, 2013 at 11:59:56 PM UTC+2, Frank Blechschmidt wrote:
>
> I already figured it out thanks to some guys in the Go+ Group :)
>
>
> On Sat, Jun 15, 2013 at 11:52 PM, Dan Kortschak > wrote:
>
>> First, you don't ned to put the slide
Hello all,
Could type parameters be omitted when they could be inferred in struct
literals?
Here's a scenario that doesn't work today
(https://go2goplay.golang.org/p/Jt5OGfLePuu)
package main
import (
"fmt"
)
type BinaryTree(type T) struct {
Value T
Left, Right *BinaryTree(T)
}
func
Suppose I want to write a function over any list like container (histogram,
reverse...) how can I? Java requires special code if you want to process arrays
— thus most code takes Lists, and accepting an array (eg a vararg) is likely to
lead to a copy into a list at some point. Is go fated to
I've now created an issue here: https://github.com/golang/go/issues/39654.
--
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
At Ben did you made a github issue yet for it? Can't seem to find it
https://github.com/golang/go/issues?q=is%3Aissue+cmd%2Fgo2go 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
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
On Wed, Jun 10, 2020 at 04:03:36PM -0700, Ian Lance Taylor wrote:
[...]
> In the current implementations of Go, Tickers are not garbage
> collected. They run until they are stopped. So if you don't stop a
> ticker, it will keep ticking until your program exits.
>
> (It is possible that future
On Wed, Jun 17, 2020 at 1:19 PM Hal wrote:
> * the syntax defining generic function is verbose on purpose (type
> keyword), not only for clarification, but also a remind of the cost and
> complexity behind generics
>
I don't know where this idea is from, but it's not accurate. The type
keyword
Sorry, I understand what you're saying now. I quite like "type T" meaning
"any type", but you have a fair point.
--
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
Hi Brian,
Thanks for your reply but I don’t think you get my point, what I mean is
constraint should be always explicitly specified, so we should not support
“optional” or “omitted” constraints.
On Wed, 17 Jun 2020 at 12:51, Brian Candler wrote:
> Consider a generic where you want T1
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"
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
"If a constraint is specified for any type parameter, every type parameter
must have a constraint. If some type parameters need a constraint and some
do not, those that do not should have a constraint of interface{}."
"interface{}" equals to "Any Type" in the context of generics. So it seems
You could save a fair amount of typing and eyestrain by not replicating the
type params for types, in their methods:
type Vector(type T) []T
func (v *Vector) Push(x v.T) { *v = append(*v, x) }
type Map(type K, V) struct {
root*node(K, V)
compare func(K, K) int
Allowing this implicit conversion would be a bad thing? because it works
like generics without any new syntax.
Also, I found this a little messy
type Ordered interface {
type int, int8, int16, int32, int64,
uint, uint8, uint16, uint32, uint64, uintptr,
Also, type arguments to generic function calls are *optional*:
https://go2goplay.golang.org/p/w-q65tL5wh-
Therefore, when looking at a foo(bar)(baz), you have to know whether (bar)
is a value or a type, which requires scanning the code to find the
definition of 'bar' in this scope or nearest
The non-generic form _only_ accepts an argument of type []Stringer. If you
have a []Foo, where Foo implements Stringer, that's not good enough. You
will have to construct a []Stringer explicitly, and copy each Foo into that
[]Stringer. This is a fairly common gotcha with Go, where folks expect the
Reading the document "Type parameters - Draft desing" of June 16, 2020
(https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md),
I wonder if these two following function definitions are not equivalent and
thus interchangeable
func Stringify(type T
for completeness' sake, there is indeed no need for pointer methods:
https://go2goplay.golang.org/p/1WD7WRAmNim
(my main point was the gotcha w/ 'func (dec *Decoder(*T)) F()')
‐‐‐ Original Message ‐‐‐
On Wednesday, June 17, 2020 9:08 AM, Sebastien Binet wrote:
> hi there,
>
> I was
hi there,
I was playing a bit w/ pointer methods[1] to see how this could be applied to a
pet peeve of mine: ensuring at compile-time that, e.g., json.Decoder.Decode
takes a pointer to a value:
https://go2goplay.golang.org/p/J2Lr5QrkKTj
this works:
func Decode(type *T)(ptr *T) error {
80 matches
Mail list logo
