Ian,
Thanks for your reply.
Yes, it's just probably because it's still early days but I was a bit confused.
Happy to note this new draft allows to define functions (and methods) that can
only take pointers to values, though.
-s
Original Message
On Jun 20, 2020, 02:12, Ian La
Such as:
* non-reflected DeepCopy, Conversion
* client-go/{informers,kubernetes/typed,listers}
--
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+unsubsc
.
--
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/
Hi!
First, thanks to the Go team for the hard work and the list populace for an
extremely low-noise list. Very much appreciated.
In the recent draft, struct methods with type parameters are explicitly
excluded with a note that they might be added later.
I think I roughly understand the added co
Or any map type with a specified key type but ignore the element type.
On Saturday, June 20, 2020 at 9:16:39 AM UTC-4, T L wrote:
>
> .
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails fr
I mean I don't care about the element and key types of the parameter type.
For a simple example, I want to define a generic function which prints the
length of a container (do do some other things):
func Print(type T Container) (v T) {
// ... do some things
fmt.Println(len(v))
// ...
I would assume it's
type MapConstraint(type K comparable, V interface{}) interface {
type map[K]V
}
func F(type M MapConstraint(K, V), K comparable, V interface{}) (m M) {
}
Note that you are under no obligation to make use of a type-parameter if
you don't need it.
On Sat, Jun 20, 2020 at 4
On Saturday, June 20, 2020 at 10:21:56 AM UTC-4, Axel Wagner wrote:
>
> I would assume it's
>
> type MapConstraint(type K comparable, V interface{}) interface {
> type map[K]V
> }
>
> func F(type M MapConstraint(K, V), K comparable, V interface{}) (m M) {
> }
>
> Note that you are under no ob
The method set of a type should be stable. Generic methods make this
impossible.
On Saturday, June 20, 2020 at 9:31:53 AM UTC-4, Carsten Orthbandt wrote:
>
> Hi!
>
> First, thanks to the Go team for the hard work and the list populace for
> an extremely low-noise list. Very much appreciated.
>
>
For example, if there is a builtin convertible(from, to) constraint,
We can define a slice conversion function as
func Convert(type Ta, Tb converitble(Ta, Tb)) (avs []Ta, _Tb) (bvs []Tb) {
bvs = make([]Tb, 0, len(avs)
for _, v := range avs {
bvs = append(bvs, Tb(v))
}
return bvs
And
* should "embeddable" be one kind of constraints?
* should "has some specified fields" be one kind of constraints?
On Saturday, June 20, 2020 at 11:26:08 AM UTC-4, T L wrote:
>
> For example, if there is a builtin convertible(from, to) constraint,
> We can define a slice conversion function as
One way to see a problem pretty immediately is that `reflect` allows you to
look up a type's method by name, but it doesn't allow you to do the same
for functions. So you'd need a runtime-representation of generic functions
of *some* sort. This is currently avoided by the restriction that you can't
Hi
How can I find the list of fields of all structs with some particular
comment using *ast*(*or maybe other tool available in the lang*)?
Using *ast.Inspect(),* we get different callbacks for diff ast nodes, like:-
- *ast.Comment :- gives comment
- *ast.TypeSpec: gives the name of the str
Will try to explain with an example --
// expectedComment
type StructNameA struct {
NameA string
AgeA int
}
// some diff comment
type StructNameB struct {
NameB string
AgeB int
}
Now I want the name of StructNameA struct along with its fields because it
contains expectedComment
Got one: https://rakyll.org/generics-proposal/
At the very bottom of the page, a person wrote a strange code
func Do(type T io.Reader)(r T) {
switch r.(type) {
case io.ReadCloser:
fmt.Println("ReadCloser")
}
}
prog.go2:19:9: r (variable of type T) is not a
I like it. Poor VSCode users will suffer from the current approach and all
these ((() – this thing can't even highlight types of function
parameters. Your variant is a lot (I mean a LOT) more readable
Also, *[]T* and *map[K]V* does not look consistent, so I don''t think this
is a true vali
PS
Also, *[]T* and *map[K]V* does not look consistent, so I don''t think this
> is a true valid reason:
I didn't mean they are inconsistent. They just don't look consistent at the
first glance.
суббота, 20 июня 2020 г., 19:06:14 UTC+3 пользователь Denis Cheremisov
написал:
>
> I like it. Poo
1st: Says who?
2nd: The method set of a type would be stable at runtime since only
instantiated methods would exist.
On Saturday, June 20, 2020 at 5:16:17 PM UTC+2, T L wrote:
>
> The method set of a type should be stable. Generic methods make this
> impossible.
>
> On Saturday, June 20, 2020 at
Reflection certainly is a potential problem. But the only actual issue I
can see is the possibility of having multiple methods of the same name on a
type. Obviously, reflect.Type.MethodByName(string) would have to either
exclude or somehow distinguish the variants under a single name.
I don't
Addendum in case I wasn't clear:
I consider the absence of type-parameterized methods a bigger problem than
potentially required extensions to the reflection interfaces. Parens,
brackets or smiles for syntax? Yeah, I do have favorites, but it's not a
big deal. Contracts or interfaces? I prefer
> And
> * should "embeddable" be one kind of constraints?
Would you elaborate what do you mean by "embeddable"?
As for the other 3, I agree it would be good to have them as constraints.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsub
Personally I am happy with the current way of expressing constraints, i.e.,
interface-like + type lists, but I do think constraints and interfaces, are
two different concepts, and forcing them into a same box does not mitigate
the extra cognitive load needed to understand generics (which, as in
Hi,
The type parameters in the current proposal uses `(type xxx)` which is visually
hard to distinguish from function parameters.
There are reasons stated in the proposal to not adopt <> (which is common in
other languages) which I'm not going to challenge. But have you considered
`()`? It sho
It's covered in the generics design doc, and by about a dozen threads on
golang-nuts at this point. Unless the parsing issues can be addressed
satisfactorily, that option is off the table right now. Same for [T] and
other variations.
- Dave
On Sat, Jun 20, 2020 at 10:34 AM wrote:
> Hi,
>
> The
Using your code as example:
> func (tl *TextList) Add(type T Stringer) (item T ) {
> tl.Data=append(tl.Data,item.String())
> }
Now if we have:
package pkg //probably written by a user you don't know that uses your code
type A struct{}
func (A) String() string { return "" }
type IA interface
On Sat, Jun 20, 2020 at 11:03 AM T L wrote:
>
>
> On Saturday, June 20, 2020 at 10:21:56 AM UTC-4, Axel Wagner wrote:
>>
>> I would assume it's
>>
>> type MapConstraint(type K comparable, V interface{}) interface {
>> type map[K]V
>> }
>>
>> func F(type M MapConstraint(K, V), K comparable, V
Maps and Slices don't have a lot of operations in common. In general, the
only ones I can think of are
- `make(T, someInt)`, though it means *very* different things for both, so
a generic function doing this is likely not super sensible
- `for _, v := range x`, though even this differs, as the orde
You have not responded to the second concern, about
interface-type-assertions requiring runtime instantiation of methods.
On Sat, Jun 20, 2020 at 6:20 PM Carsten Orthbandt <
carsten.orthba...@gmail.com> wrote:
> Reflection certainly is a potential problem. But the only actual issue I
> can see is
Also, just FTR, I agree with you that it would be nice to have
type-parameters on methods. I would very much like it if there was a way to
make it work.
However, your tone is very confrontational. The people who wrote that
design have spent a lot more time on thinking about this than you and you
sh
Generally, you are looking for a `*ast.GenDecl` and its doc, which contains
a `ast.TypeSpec`, when it is written as `type Name Type{ ... }`. However,
though nearly never happened, people can write it as `type ( Name
Type{} )`, just like a `var` statement would. In that case, you are
lookin
On Sat, Jun 20, 2020 at 8:26 AM T L wrote:
>
> For example, if there is a builtin convertible(from, to) constraint,
> We can define a slice conversion function as
>
> func Convert(type Ta, Tb converitble(Ta, Tb)) (avs []Ta, _Tb) (bvs []Tb) {
>bvs = make([]Tb, 0, len(avs)
>for _, v := range
On Sat, Jun 20, 2020 at 8:35 AM T L wrote:
>
> And
> * should "embeddable" be one kind of constraints?
> * should "has some specified fields" be one kind of constraints?
Being able to express every possible language concept in a constraint
is not a goal.
Also, this kind of extension can typicall
On Sat, Jun 20, 2020 at 12:08 PM David Finkel wrote:
>
> Here's an almost working example:
> https://go2goplay.golang.org/p/qcdfl0tuHlb
>
> It looks like there's a bug in the type-parameter constraint checking because
> in the above example code, I get:
>
> type checking failed for main
>
> prog.
On Fri, Jun 19, 2020 at 1:50 PM Bryan C. Mills wrote:
>
> On Fri, Jun 19, 2020 at 2:38 PM Ian Lance Taylor wrote:
>>
>> On Fri, Jun 19, 2020 at 9:31 AM Bryan C. Mills wrote:
>> >
>> > On Fri, Jun 19, 2020 at 1:30 AM Ian Lance Taylor wrote:
>> >>
>> >> This code is acting as though, if ordinary
And there goes my illusion about golang-nuts being a constructive discussion.
Thanks, I'm 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 golang-nuts+unsubs
Can you have multiple go routines waiting to read from a socket, or are you
limited to just one?
--
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+unsu
I really like how the latest generics draft has progressed, fantastic
work. The only thing that doesn't really feel perfect yet is type
lists.
I like the idea of all constraints being interfaces and I get why
interfaces with type lists and/or comparable are only constraints for
now. I'd rather the
On Sat, Jun 20, 2020 at 3:47 PM wrote:
> Can you have multiple go routines waiting to read from a socket, or are
> you limited to just one?
>
Yes, you can have multiple readers of a socket. But the results will be
unpredictable. Especially if it's a SOCK_STREAM (e.g., TCP) socket. You
should onl
Yesterday we replaced the old gonum.org site with a new hugo build.
This appears to have broken go get for clients that do not use
proxy.golang.org or some other proxy that already has gonum.org/...
cached (this includes gddo).
```
$ GOPROXY=direct go get gonum.org/v1/gonum
go get gonum.org/v1/gon
Closing the loop on this. They reached out in the Gopher Slack and we
pieced it together:
- https://gophers.slack.com/archives/C029RQSEE/p1592699134083700
It has to do with this section of code:
-
https://github.com/golang/go/blob/60f78765022a59725121d3b800268adffe78bde3/src/cmd/go/internal/ge
On Saturday, June 20, 2020 at 1:10:29 PM UTC-4, Bebop Leaf wrote:
>
>
>
> > And
> > * should "embeddable" be one kind of constraints?
>
> Would you elaborate what do you mean by "embeddable"?
>
> As for the other 3, I agree it would be good to have them as constraints.
>
For example:
type Foo(t
On Saturday, June 20, 2020 at 4:48:07 PM UTC-4, Ian Lance Taylor wrote:
>
> On Sat, Jun 20, 2020 at 8:26 AM T L >
> wrote:
> >
> > For example, if there is a builtin convertible(from, to) constraint,
> > We can define a slice conversion function as
> >
> > func Convert(type Ta, Tb converitb
On Saturday, June 20, 2020 at 3:08:42 PM UTC-4, David Finkel wrote:
>
>
>
> On Sat, Jun 20, 2020 at 11:03 AM T L >
> wrote:
>
>>
>>
>> On Saturday, June 20, 2020 at 10:21:56 AM UTC-4, Axel Wagner wrote:
>>>
>>> I would assume it's
>>>
>>> type MapConstraint(type K comparable, V interface{}) inte
Thanks to Tim and Eric Bajumpaa on slack.
The issue was due to an error in minification where the quotes around
the name attribute value are stripped. Turning off minification is an
interim workaround while that is broken.
Dan
On Sat, 2020-06-20 at 18:10 -0700, Tim Heckman wrote:
> Closing the l
On Sat, Jun 20, 2020 at 4:53 PM Ian Lance Taylor wrote:
> On Sat, Jun 20, 2020 at 12:08 PM David Finkel
> wrote:
> >
> > Here's an almost working example:
> > https://go2goplay.golang.org/p/qcdfl0tuHlb
> >
> > It looks like there's a bug in the type-parameter constraint checking
> because in the
the draft lays out an example function GeneralAbsDifference. these
comments build around that. i wanted to see how far i could get towards
working specialization within this framework. the baseline assumption is
that when specialization is required today the acceptable amount of type
switching/a
The idea of having development and release compilation modes sounds
appealing at first, though I'm a bit skeptical about how it would turn out.
This would mean that, during development, you wouldn't have a full
understanding of the performance characteristics of your program.
Admittedly, that's not
47 matches
Mail list logo
