On Tuesday, 4 August 2020 at 00:34:12 UTC+2 ben...@gmail.com wrote:
> Which at first seems like a good idea, but then unless "any" is built in
> or this becomes a well-known idiom, it won't be as self-documenting. Other
> people will have to look up the definition to see "oh, I see, this is
FWIW, the "generic types" alternative syntax proposal:
https://github.com/golang/go/issues/39669 includes an explicit distinction
between generic interfaces and regular interfaces, and an earlier iteration of
this idea included a new keyword, e.g., `prototype`, that would signal this
Thanks for the thoughtful response.
> I'm still strongly in favor of not having it. In particular, there is a large
> section of conceptual overlap between interfaces and constrained
> type-parameters. And at least as far as function parameters go, an interface
> parameter can always be
On Tue, Aug 4, 2020 at 1:01 AM Ben Hoyt wrote:
> In terms of a "solution" for this, one that I'm sure has been thought
> about: what about keeping type constraints and interfaces completely
> separate? They are half the time anyway (when there are type lists),
> so why not make them separate all
On Mon, 2020-08-03 at 10:45 -0700, Ian Lance Taylor wrote:
> Another possibility is constraints.Any, although that is no shorter
> than interface{}. I'm not sure _ is best; currently _ fairly
> consistently means "ignore this value," but in this usage it would
> mean something different.
Another
Per Ian's suggestion on the other thread I started
(https://groups.google.com/g/golang-nuts/c/u9jqLPhEYO0/m/tnqezci8AwAJ),
I'm breaking out this topic into a separate thread:
It seems strange to me that interfaces with type lists are really a
different beast than regular interfaces, and aren't
> That is an experiment. We don't seem to need the type keyword for
> generic functions. But we do need it for generic types, to avoid
> confusion with an array type (but only if there is exactly one type
> parameter with no constraint). I'm not personally a big fan of
> optional syntax, so we
On Monday, 3 August 2020 at 19:46:05 UTC+2 Ian Lance Taylor wrote:
> Yet another possibility, going back to the syntax question above, is
> requiring that a type parameter for a type alway have a constraint,
> which would mean that we would never use the "type" keyword for type
> parameters,
I'm using the go-kit/kit/log
(https://pkg.go.dev/github.com/go-kit/kit/log?tab=doc#Logger) abstraction:
Log(keyvals ...interface{}) error
This can be set in my library, and uses with logfmt, if given.
leo.b...@npo-data.nl a következőt írta (2020. augusztus 3., hétfő, 18:33:11
UTC+2):
>
Hello gophers,
We plan to issue Go 1.14.7 and Go 1.13.15 on Thursday, August 6.
These are minor releases that include a security fix.
Following our policy at https://golang.org/security,
this is the pre-announcement of those releases.
Cheers,
Katie and Filippo on behalf of the Go team
Thanks for confirming Ian, this is very helpful. I agree with the
implication that hacking Go on x86 to avoid TLS would not be a productive
use of time compared to adding TLS support to the operating system.
Thanks again.
On Sat, Aug 1, 2020 at 6:27 PM Ian Lance Taylor wrote:
> On Sat, Aug 1,
On Mon, Aug 3, 2020 at 1:48 AM Ben Hoyt wrote:
>
> I've played with generics a bit more, including the new square
> brackets syntax. A few notes (some of the threads have been long, so
> apologies if I'm doubling up):
Thanks for the extensive feedback.
> Related question: why does the current
Not sure if this is what you are looking for, but
https://github.com/go-logr/logr seems to address log abstraction.
On Friday, July 31, 2020 at 3:05:03 AM UTC+2 fai...@google.com wrote:
> I have a library that is used by cross platform binaries running in corp.
> Some of these binaries don't
se the combination of "-source_path" and "-trim_path" still not work
my project dir tree
macbookpro:tejia_analysis fredlee$ pwd
/Users/fredlee/Documents/xxx/tool/tejia_analysis
macbookpro:tejia_analysis fredlee$ tree util
util
├── analysis.go
├── configure.go
├── cron.go
├──
I've played with generics a bit more, including the new square
brackets syntax. A few notes (some of the threads have been long, so
apologies if I'm doubling up):
1) I definitely prefer the square brackets syntax. It makes it clear
where you're using type parameters, and IMO it sets them off much
15 matches
Mail list logo
