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
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
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
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(
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-inter
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 stil
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
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
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 str
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
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.
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
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 st
" 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
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"
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
16 matches
Mail list logo
