[go-nuts] Re: who is mike?
Mike Burrows https://en.wikipedia.org/wiki/Michael_Burrows On Sunday, June 28, 2020 at 3:51:27 PM UTC-7, Bill Morgan wrote: > > who is mike wrt this commit? > > commit bc0b4f0d2a610059afb95ef0360704714815187d > Author: Ken Thompson > > Date: Thu Nov 13 10:35:44 2008 -0800 > > mike's map code > > R=r > OCL=19146 > CL=19146 > -- 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/45d4dc92-68c1-4fb7-89b3-c170ba445533o%40googlegroups.com.
[go-nuts] who is mike?
who is mike wrt this commit? commit bc0b4f0d2a610059afb95ef0360704714815187d Author: Ken Thompson Date: Thu Nov 13 10:35:44 2008 -0800 mike's map code R=r OCL=19146 CL=19146 -- 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/ad88ffda-841c-4c22-a420-3d9210b2c1deo%40googlegroups.com.
Re: [go-nuts] [generic] Readibility of Multiple Parenthsis
On Sun, Jun 28, 2020 at 2:56 PM wrote:
>
> After looking at the latest proposal -
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md,
> and also checked a curated list of discussion at -
> https://groups.google.com/forum/#!msg/golang-nuts/uQDrcHDwT_w/Y-Myzuw_AQAJ.
>
> However, I do find myself still interested in a case like below:
>
> type foo struct{}
>
> func bar(x int) func(int) int {
> return func(y int) int {
> return x + y
> }
> }
>
> func main() {
> foo := 1
> result := bar(foo)(2)
> fmt.Println(result)
> }
>
> I believe a function which returns another function in current Go world is
> pretty normal. I specifically mocked an example above - where the first
> parameter name appears to collide with a type name.
>
> With that said, I guess compiler won't have any issues to figure it out when
> it is type parameter and when it is not. However, I think that's not trivial
> for a human, though.
>
> So is this a problem or I may just have ignored anything?
There are many ways to write ambiguous code in Go, or in any
programming language. The interesting question here is not "can it be
ambiguous?" It is "will it be ambiguous in practice?" That is why I
am encouraging people to write real code using the design draft, so
that we can see how that real code looks.
In particular, the ambiguity in your example hinges on a collision
between a variable name and a type name. In Go, for better or for
worse, variable names and type names live in the same namespace and
can shadow each other. Yet people are rarely confused by this in
practice. Real code rarely uses identifiers like "foo". In real
code, when we look at an identifier, how often are we confused as to
whether that identifier is a variable, a function, a type, or a
constant? And how often do those confusing cases collide with a case
like a function that returns a function that is immediately called?
I can guess answers to those questions, but I don't know. The only
way to know is to look at real code.
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/CAOyqgcX6Bo_fR%3D%3DDSFOKDUjEw%2B%3Drvy2OT5Ut-7%3D25fVuyqeNjA%40mail.gmail.com.
Re: [go-nuts] [generics] Typo in draft
On Sun, Jun 28, 2020 at 1:45 PM Diego Augusto Molina
wrote:
>
> Hi, I think I spotted a small typo in the draft. In Examples >
> Containers we have:
>
> // Find returns the value associated with a key, or zero if not present.
> // The bool result reports whether the key was found.
> func (m *Map(K, V)) Find(k K) (V, bool) {
> pn := m.find(k)
> if *pn == nil {
> var zero val // see the discussion of zero values, above
> return zero, false
> }
> return (*pn).v, true
> }
>
>
> Whereas I think it should be:
>
> // Find returns the value associated with a key, or zero if not present.
> // The bool result reports whether the key was found.
> func (m *Map(K, V)) Find(k K) (V, bool) {
> pn := m.find(k)
> if *pn == nil {
> var zero V // see the discussion of zero values, above
> return zero, false
> }
> return (*pn).v, true
> }
>
>
> Patch attached.
Thanks, sent https://golang.org/cl/240340.
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/CAOyqgcXkdSCY3L3784bttbNTgAxz4Ap_OzV41kbPQ7Jd4bqsZA%40mail.gmail.com.
Re: [go-nuts] [generics] type list should not pass newtypes
On Sun, Jun 28, 2020 at 9:37 AM tdakkota wrote: > > When I say 'it's not Go-1like' I mean that MyInt type is not equal to int > type in Go1 type system. > reflect.DeepEqual(int(0), MyInt(0)) returns false. > Type assertion fails. > That's why I call it 'newtype'. > > But type lists with non-interface types have a different logic. MyInt type is > equal to int. > But, also, it requires explicit conversation to interface type: > https://go2goplay.golang.org/p/2Ue3BlYBXyB. You cannot use underlying type as > T Constr. > It seems incorrect, when I write `type int` it means that only `int` should > be permitted, not `MyInt/MySuperInt/etc.` I think I've explained why it is really essential that we be able to match on underlying types. If you feel that type lists should only match on identical types, then what do you suggest we should use to match on underlying types? Then perhaps we can do that, and remove type lists. I'm somewhat sympathetic to the goal, but type lists matching on underlying types are the best idea we've had so far. We can't just start matching on identical types only. That won't be satisfactory, as I've tried to explain. Thanks. Ian > воскресенье, 28 июня 2020 г. в 06:13:31 UTC+3, Ian Lance Taylor: >> >> On Sat, Jun 27, 2020 at 3:06 PM tdakkota wrote: >> > >> > I think, if I want int/[]int, I should use int/[]int or just declare a >> > domain specific alias. >> > MyInt/[]MyInt should implement Lesser/Min/etc interface. It can declare >> > specific comparison rules. >> > >> > Min implementation can be like: https://go2goplay.golang.org/p/Fgo2fJAlKXD >> > (this code does not compile, I don't know why) >> > >> > My point is that this decision is not Go1-like and can cause unexpected >> > runtime errors. >> >> If we don't match on underlying types, then we can't use the < >> operator on elements of a value of type []MyInt. Requiring people to >> explicitly declare a Less method on an integer type seems like >> unnecessary boilerplate that should be avoided. If we're going to do >> that, why have type lists at all? Why not always require people to >> declare a method? >> >> Your example doesn't compile because Go doesn't have any conversion >> from a slice of one type to a slice of a different type. >> >> Go today has nothing like type lists. I don't agree that having type >> lists match underlying types is not Go1-like, because I don't think >> current Go has anything to say about type lists. >> >> Ian >> >> >> > суббота, 27 июня 2020 г. в 23:03:25 UTC+3, Ian Lance Taylor: >> >> >> >> On Sat, Jun 27, 2020 at 12:35 PM a b wrote: >> >> > >> >> > Newtype is a expression like >> >> > type MyInt int >> >> > >> >> > It's not the same type as int, so why it's permitted? >> >> > In Go1 you must perform explicit conversion. >> >> >> >> Because if you have a []MyInt, it would be nice to be able to pass >> >> that to a function like slices.Min. Note that you can't directly >> >> convert []MyInt to []int. >> >> >> >> 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...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/golang-nuts/5b246c09-e64b-47ff-b2ef-1c4f9ea7ea94n%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/e21310a0-d7b4-4c2e-9b6d-8ff8530522b8n%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/CAOyqgcU0B2gR0isyNV%3Da0ZBnG7-rh4RW5G2xr781f%2BL-dAkwXQ%40mail.gmail.com.
[go-nuts] [generic] Readibility of Multiple Parenthsis
Hi,
After looking at the latest proposal -
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md,
and also checked a curated list of discussion at -
https://groups.google.com/forum/#!msg/golang-nuts/uQDrcHDwT_w/Y-Myzuw_AQAJ.
However, I do find myself still interested in a case like below:
type foo struct{}
func bar(x int) func(int) int {
return func(y int) int {
return x + y
}
}
func main() {
foo := 1
result := bar(foo)(2)
fmt.Println(result)
}
I believe a function which returns another function in current Go world is
pretty normal. I specifically mocked an example above - where the first
parameter name appears to collide with a type name.
With that said, I guess compiler won't have any issues to figure it out
when it is type parameter and when it is not. However, I think that's not
trivial for a human, though.
So is this a problem or I may just have ignored anything?
Thanks,
Haibing
--
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/16b683af-b8cc-4e5f-b1b2-1c05da7e0c56o%40googlegroups.com.
[go-nuts] [generics] Typo in draft
Hi, I think I spotted a small typo in the draft. In Examples >
Containers we have:
// Find returns the value associated with a key, or zero if not present.
// The bool result reports whether the key was found.
func (m *Map(K, V)) Find(k K) (V, bool) {
pn := m.find(k)
if *pn == nil {
var zero val // see the discussion of zero values, above
return zero, false
}
return (*pn).v, true
}
Whereas I think it should be:
// Find returns the value associated with a key, or zero if not present.
// The bool result reports whether the key was found.
func (m *Map(K, V)) Find(k K) (V, bool) {
pn := m.find(k)
if *pn == nil {
var zero V // see the discussion of zero values, above
return zero, false
}
return (*pn).v, true
}
Patch attached.
--
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/CAGOxLdF76jLN0WCtPHP7FL1chVTJ5WJkf9%2BAmhVPgsyhh4W9OA%40mail.gmail.com.
fix-typo.patch
Description: Binary data
Re: [go-nuts] [generics] Syntax feedback
Tyler, May I humbly suggest https://groups.google.com/d/msg/golang-nuts/W3fSnH0w1G0/JbMkJrKICAAJ for an additional item for your list? Thank you very much, Andrey On Saturday, June 27, 2020 at 11:46:23 AM UTC-6, Tyler Compton wrote: > > Hi Rob, > > This topic has been discussed many times on this list, so it's probably > best to look at and post in one of those threads. Let me take this chance > to collect as much information about this issue as I can in a single post. > Unfortunately, discoverability can sometimes be hard on mailing lists so I > don't blame you for not seeing all these. > > Responses on the subject: > Design draft talking about alternative syntax: > https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use-the-syntax-like-c_and-java > Ian's justification for taking a wait-and-see approach to this syntax > issue: https://groups.google.com/g/golang-nuts/c/Rumm5HFhg_Q > > Threads: > Use "<>": https://groups.google.com/g/golang-nuts/c/LvkOBA2D_Bk > Use "<>": https://groups.google.com/g/golang-nuts/c/B1Q1dsLa5rk > Use "::" and other suggestions: > https://groups.google.com/g/golang-nuts/c/b0GydCIn7T0 > Use "(<>)": https://groups.google.com/g/golang-nuts/c/tYwWeiMztiI > Use "<>" before the name of the type being defined: > https://groups.google.com/g/golang-nuts/c/TJWGbrx2o34 > Put type parameters in the regular arguments list with a ":type" suffix: > https://groups.google.com/g/golang-nuts/c/K7s-5MeXuzM > Use "<>", with some kind of additional syntax to make parsing easier: > https://groups.google.com/g/golang-nuts/c/SaDkSQdgF9g > Use "<>": https://groups.google.com/g/golang-nuts/c/coi7YS0KPgQ > Use "<>": https://groups.google.com/g/golang-nuts/c/ydySSqZqi-0 > Use ":[]": https://groups.google.com/g/golang-nuts/c/zGQq_I5r2jg > No specific suggestion: > https://groups.google.com/g/golang-nuts/c/mY_36VU5ij8 > > -- 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/32da9686-d144-4d35-924f-b2bb1de7d9b3o%40googlegroups.com.
[go-nuts] text template and white space suppression
I am trying to do some creative formatting using text template and wanted
to see if there might be a better approach than what I implemented.
I have an array of structs, where each element has a Project and Task. The
array is sorted by Project.
type DisplayTask struct {
Project string
Task string
}
I want to output all the tasks within a project without repeating the
project name each time and I want the tasks to be indented, for example:
Project1
Task1
Task2
Project2
Task3
Project3
Task4
Task5
After much experimentation, I am using the following template and trying to
determine if there is a way to avoid the printf and just have the indent as
part of the template, but I can't figure out a way to do this and suppress
white space (newline) from the if statement for the same project.
{{- $lastProject := "" -}}
{{ range . }}
{{- if (ne $lastProject .Project) -}}
{{ .Project }} {{ $lastProject = .Project }}
{{ end -}}
{{ printf " %s" .Task }}
{{ end -}}
Go Playground of the working code is at
https://play.golang.org/p/3qqVW8lN-Ha
The challenge I had was suppressing white space after the end, but still
allowing an indent via white space, so resorted to the printf.
Is there a better 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/8da74f77-a462-4bdf-9491-38e403d8c250o%40googlegroups.com.
Re: [go-nuts] [generics] type list should not pass newtypes
These type lists that are used in generic interfaces are not sum types. they are there to allow restrictions on operators, since only base types have operators in go (and types which use them as underlying types inherit). You are thinking of sum types, which go does not have. On Sunday, June 28, 2020 at 7:37:02 PM UTC+3, tdakkota wrote: > > When I say 'it's not Go-1like' I mean that MyInt type is not equal to int > type > in Go1 type system. > reflect.DeepEqual(int(0), MyInt(0)) returns false. > Type assertion fails. > That's why I call it 'newtype'. > > But type lists with non-interface types have a different logic. MyInt type > is equal to int. > But, also, it requires explicit conversation to interface type: > https://go2goplay.golang.org/p/2Ue3BlYBXyB. You cannot use underlying > type as T Constr. > It seems incorrect, when I write `type int` it means that only `int` > should be permitted, not `MyInt/MySuperInt/etc.` > > > > > воскресенье, 28 июня 2020 г. в 06:13:31 UTC+3, Ian Lance Taylor: > >> On Sat, Jun 27, 2020 at 3:06 PM tdakkota wrote: >> > >> > I think, if I want int/[]int, I should use int/[]int or just declare a >> domain specific alias. >> > MyInt/[]MyInt should implement Lesser/Min/etc interface. It can declare >> specific comparison rules. >> > >> > Min implementation can be like: >> https://go2goplay.golang.org/p/Fgo2fJAlKXD (this code does not compile, >> I don't know why) >> > >> > My point is that this decision is not Go1-like and can cause unexpected >> runtime errors. >> >> If we don't match on underlying types, then we can't use the < >> operator on elements of a value of type []MyInt. Requiring people to >> explicitly declare a Less method on an integer type seems like >> unnecessary boilerplate that should be avoided. If we're going to do >> that, why have type lists at all? Why not always require people to >> declare a method? >> >> Your example doesn't compile because Go doesn't have any conversion >> from a slice of one type to a slice of a different type. >> >> Go today has nothing like type lists. I don't agree that having type >> lists match underlying types is not Go1-like, because I don't think >> current Go has anything to say about type lists. >> >> Ian >> >> >> > суббота, 27 июня 2020 г. в 23:03:25 UTC+3, Ian Lance Taylor: >> >> >> >> On Sat, Jun 27, 2020 at 12:35 PM a b wrote: >> >> > >> >> > Newtype is a expression like >> >> > type MyInt int >> >> > >> >> > It's not the same type as int, so why it's permitted? >> >> > In Go1 you must perform explicit conversion. >> >> >> >> Because if you have a []MyInt, it would be nice to be able to pass >> >> that to a function like slices.Min. Note that you can't directly >> >> convert []MyInt to []int. >> >> >> >> 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...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/5b246c09-e64b-47ff-b2ef-1c4f9ea7ea94n%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/eea835d5-6773-41be-a7da-fa1807c5e504o%40googlegroups.com.
Re: [go-nuts] [generics] type list should not pass newtypes
When I say 'it's not Go-1like' I mean that MyInt type is not equal to int type in Go1 type system. reflect.DeepEqual(int(0), MyInt(0)) returns false. Type assertion fails. That's why I call it 'newtype'. But type lists with non-interface types have a different logic. MyInt type is equal to int. But, also, it requires explicit conversation to interface type: https://go2goplay.golang.org/p/2Ue3BlYBXyB. You cannot use underlying type as T Constr. It seems incorrect, when I write `type int` it means that only `int` should be permitted, not `MyInt/MySuperInt/etc.` воскресенье, 28 июня 2020 г. в 06:13:31 UTC+3, Ian Lance Taylor: > On Sat, Jun 27, 2020 at 3:06 PM tdakkota wrote: > > > > I think, if I want int/[]int, I should use int/[]int or just declare a > domain specific alias. > > MyInt/[]MyInt should implement Lesser/Min/etc interface. It can declare > specific comparison rules. > > > > Min implementation can be like: > https://go2goplay.golang.org/p/Fgo2fJAlKXD (this code does not compile, I > don't know why) > > > > My point is that this decision is not Go1-like and can cause unexpected > runtime errors. > > If we don't match on underlying types, then we can't use the < > operator on elements of a value of type []MyInt. Requiring people to > explicitly declare a Less method on an integer type seems like > unnecessary boilerplate that should be avoided. If we're going to do > that, why have type lists at all? Why not always require people to > declare a method? > > Your example doesn't compile because Go doesn't have any conversion > from a slice of one type to a slice of a different type. > > Go today has nothing like type lists. I don't agree that having type > lists match underlying types is not Go1-like, because I don't think > current Go has anything to say about type lists. > > Ian > > > > суббота, 27 июня 2020 г. в 23:03:25 UTC+3, Ian Lance Taylor: > >> > >> On Sat, Jun 27, 2020 at 12:35 PM a b wrote: > >> > > >> > Newtype is a expression like > >> > type MyInt int > >> > > >> > It's not the same type as int, so why it's permitted? > >> > In Go1 you must perform explicit conversion. > >> > >> Because if you have a []MyInt, it would be nice to be able to pass > >> that to a function like slices.Min. Note that you can't directly > >> convert []MyInt to []int. > >> > >> 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...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/5b246c09-e64b-47ff-b2ef-1c4f9ea7ea94n%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/e21310a0-d7b4-4c2e-9b6d-8ff8530522b8n%40googlegroups.com.
[go-nuts] class is invalid in multicast dns record for srv and txt
Hi, I am using gopacket for parsing mDNS packet. following things are missing in the decode logic of mDNS packets: 1. cache flush field is not present in DNSResourceRecord struct 2. cache flush bit and class is combine as Class struct member. Due to point 2, Class variable will be getting invalid value if cache bit is set for this record. For example: Assume, if Class of the record is IN and cache flush is not set then Class struct variable will have value of 0x0001 If Class of record is IN and cache flush is SET then class struct will have value of 0x8001 When we decode this packet DNSResourceRecord.Class will have 0x8001 and this is invalid. -- 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/138faac5-9d90-47dd-93da-bd4a8ab5b7d5o%40googlegroups.com.
Re: [go-nuts] Generics feedback
Hello Calum,
One FYI that Tyler Compton pulled together a helpful list of dozen or so
different alternative generics syntax suggestions along with their
corresponding recent golang-nuts threads:
https://groups.google.com/d/msg/golang-nuts/uQDrcHDwT_w/Y-Myzuw_AQAJ
That could be a helpful starting point, including to see what the prior
response might have been from Ian Lance Taylor and others.
One link listed there that is especially worth a read is the second link in
the list there, which is a longer explanation from Ian on his rationale for
him personally wanting to take a "wait and see" approach on the syntax.
For your particular example, I think it reads slightly cleaner in the Go2Go
Playground:
https://go2goplay.golang.org/p/S3Fgmgmblr0
The fixed-width font, the 2 extra spaces added by gofmt (compared to how
you had formatted it in your post), and the 'Print' function that parallels
your 'Combine' function all help at least slightly. That said, I don't
personally know if the current syntax is the best syntax, but it also seems
that the people who have spent the most time on the syntax are also saying
they don't know if the current syntax is the best syntax and that time and
more real examples are needed before really anyone will know.
In some sense, rather than you being "late to the party", you might
actually be early to the party ;-)
Regards,
thepudds
On Sunday, June 28, 2020 at 8:58:56 AM UTC-4, Calum Shaw-Mackay wrote:
>
>
> " I believe over time, it will a) become clear that generic code will be
> less common than people think (I hope) and b) that you get used to the
> syntax either way. (also, yes, this has been discussed before, ad nauseam
> in fact :) )”
>
> Yes I also hope that the need to generify everything is kept to an
> absolute minimum.
>
> Apologies about discussing things already spoken about, I have arrived
> fairly late to this party :)
>
>
> On 28 Jun 2020, at 12:23, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com > wrote:
>
> Readability, at the end of the day, is subjective.
> So, personally: Yes, I absolutely find it more readable than any
> alternative that has been suggested. Personally, when I see code using a
> bunch of extra symbols that have special meaning (Perl and Haskell are
> extreme examples), I tend to "zone out" and find it really hard to actually
> make the effort of trying to parse it. I really like Go's general approach
> of using fewer separators and keywords to convey meaning.
>
> But in any case: I believe over time, it will a) become clear that generic
> code will be less common than people think (I hope) and b) that you get
> used to the syntax either way. (also, yes, this has been discussed before,
> ad nauseam in fact :) )
>
> On Sun, Jun 28, 2020 at 11:16 AM Calum Shaw-Mackay > wrote:
>
>> Hi all -
>>
>> I know that there’s have been numerous threads regarding the syntax for
>> declaring generic types etc, and at it’s core Go is a language that can do
>> a lot without syntactic sugar just for the sake of it, but sometimes that
>> syntactic sugar helps in a fundamental way - legibility.
>>
>> Observe this function declaration
>>
>> func Combine(type T)(s []T) (T,error){
>> ….
>> }
>>
>> Do we think that 3 consecutive clauses wrapped in parentheses is legible,
>> that the intent of both the function and its constraints are easily
>> discernible?
>> To me, and it is only my opinion, unless (type T) has different
>> ‘versions’ i.e. (struct T) or (func T), isn’t "(type " not only redundant
>> but reduces readability?
>>
>> Apologies if this has been discussed before.
>>
>> Calum
>>
>>
>> --
>> 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/6661399B-BF48-4D15-802C-E2B1C6C0F348%40gmail.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/CAEkBMfHO0hvNKT8tVM2tXk1trDbRFqJaGH%3DWtParweJiJQNQbg%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/1d7cbc1f-5351-4dda-8018-c019808e70f7o%40googlegroups.com.
Re: [go-nuts] Generics feedback
" I believe over time, it will a) become clear that generic code will be less
common than people think (I hope) and b) that you get used to the syntax either
way. (also, yes, this has been discussed before, ad nauseam in fact :) )”
Yes I also hope that the need to generify everything is kept to an absolute
minimum.
Apologies about discussing things already spoken about, I have arrived fairly
late to this party :)
> On 28 Jun 2020, at 12:23, 'Axel Wagner' via golang-nuts
> wrote:
>
> Readability, at the end of the day, is subjective.
> So, personally: Yes, I absolutely find it more readable than any alternative
> that has been suggested. Personally, when I see code using a bunch of extra
> symbols that have special meaning (Perl and Haskell are extreme examples), I
> tend to "zone out" and find it really hard to actually make the effort of
> trying to parse it. I really like Go's general approach of using fewer
> separators and keywords to convey meaning.
>
> But in any case: I believe over time, it will a) become clear that generic
> code will be less common than people think (I hope) and b) that you get used
> to the syntax either way. (also, yes, this has been discussed before, ad
> nauseam in fact :) )
>
> On Sun, Jun 28, 2020 at 11:16 AM Calum Shaw-Mackay
> mailto:calum.shawmac...@gmail.com>> wrote:
> Hi all -
>
> I know that there’s have been numerous threads regarding the syntax for
> declaring generic types etc, and at it’s core Go is a language that can do a
> lot without syntactic sugar just for the sake of it, but sometimes that
> syntactic sugar helps in a fundamental way - legibility.
>
> Observe this function declaration
>
> func Combine(type T)(s []T) (T,error){
> ….
> }
>
> Do we think that 3 consecutive clauses wrapped in parentheses is legible,
> that the intent of both the function and its constraints are easily
> discernible?
> To me, and it is only my opinion, unless (type T) has different ‘versions’
> i.e. (struct T) or (func T), isn’t "(type " not only redundant but reduces
> readability?
>
> Apologies if this has been discussed before.
>
> Calum
>
>
> --
> 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/6661399B-BF48-4D15-802C-E2B1C6C0F348%40gmail.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/CAEkBMfHO0hvNKT8tVM2tXk1trDbRFqJaGH%3DWtParweJiJQNQbg%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/427170BA-3A5B-473D-B109-F7ECA275838A%40gmail.com.
Re: [go-nuts] Generics feedback
Readability, at the end of the day, is subjective.
So, personally: Yes, I absolutely find it more readable than any
alternative that has been suggested. Personally, when I see code using a
bunch of extra symbols that have special meaning (Perl and Haskell are
extreme examples), I tend to "zone out" and find it really hard to actually
make the effort of trying to parse it. I really like Go's general approach
of using fewer separators and keywords to convey meaning.
But in any case: I believe over time, it will a) become clear that generic
code will be less common than people think (I hope) and b) that you get
used to the syntax either way. (also, yes, this has been discussed before,
ad nauseam in fact :) )
On Sun, Jun 28, 2020 at 11:16 AM Calum Shaw-Mackay <
calum.shawmac...@gmail.com> wrote:
> Hi all -
>
> I know that there’s have been numerous threads regarding the syntax for
> declaring generic types etc, and at it’s core Go is a language that can do
> a lot without syntactic sugar just for the sake of it, but sometimes that
> syntactic sugar helps in a fundamental way - legibility.
>
> Observe this function declaration
>
> func Combine(type T)(s []T) (T,error){
> ….
> }
>
> Do we think that 3 consecutive clauses wrapped in parentheses is legible,
> that the intent of both the function and its constraints are easily
> discernible?
> To me, and it is only my opinion, unless (type T) has different ‘versions’
> i.e. (struct T) or (func T), isn’t "(type " not only redundant but reduces
> readability?
>
> Apologies if this has been discussed before.
>
> Calum
>
>
> --
> 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/6661399B-BF48-4D15-802C-E2B1C6C0F348%40gmail.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/CAEkBMfHO0hvNKT8tVM2tXk1trDbRFqJaGH%3DWtParweJiJQNQbg%40mail.gmail.com.
[go-nuts] Generics feedback
Hi all -
I know that there’s have been numerous threads regarding the syntax for
declaring generic types etc, and at it’s core Go is a language that can do a
lot without syntactic sugar just for the sake of it, but sometimes that
syntactic sugar helps in a fundamental way - legibility.
Observe this function declaration
func Combine(type T)(s []T) (T,error){
….
}
Do we think that 3 consecutive clauses wrapped in parentheses is legible, that
the intent of both the function and its constraints are easily discernible?
To me, and it is only my opinion, unless (type T) has different ‘versions’ i.e.
(struct T) or (func T), isn’t "(type " not only redundant but reduces
readability?
Apologies if this has been discussed before.
Calum
--
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/6661399B-BF48-4D15-802C-E2B1C6C0F348%40gmail.com.
