Re: [go-nuts] Re: Generics and parentheses

On Tue, Jul 14, 2020 at 10:14 PM Ian Lance Taylor wrote: > > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W. > wrote: > > > > This feels a little better, but honestly I'm still all for angle brackets > > or like Watson suggested, guillamets. > > > > fn(T1)(fn2(T2)(fn3(T3)(v))) // 1 > >

Re: [go-nuts] Generics and parentheses

If the generic expression was always attached/constrained to the "type" or "func" keyword (rather than the type or function name), perhaps this would decrease the lookahead problems with lexing? For example: *type Point struct {* *x, y int* *data T* *}* *type Transformer interface {*

Re: [go-nuts] Generics and parentheses

My opinion is that every major language (no flames please… lots of developers write lots of programs and make money doing it) that supports generics uses < > for generic types, so Go should too - since there is no reason to deviate from this other than to avoid changes to the parser. Seems

Re: [go-nuts] Re: Generics and parentheses

On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W. wrote: > > This feels a little better, but honestly I'm still all for angle brackets or > like Watson suggested, guillamets. > > fn(T1)(fn2(T2)(fn3(T3)(v))) // 1 > fn[T1](fn2[T2](fn3[T3](v))) // 2 > fn(fn2(fn3(v))) // 3 >

[go-nuts] Re: Generics and parentheses

I'm partial to [], which was used for generics in the Tartan language (1978). For example generic func F[Mult: Int](X:Int) y:Int: begin y := Mult * X end https://apps.dtic.mil/dtic/tr/fulltext/u2/a062815.pdf, page 4 -- You received this message because you are subscribed to the Google

[go-nuts] Ignite go library

Hi Is there any thin client for Ignite by go? https://ignite.apache.org/docs-and-apis.html I didn't see the official one. 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

Re: [go-nuts] Re: Generics and parentheses

On Tue, Jul 14, 2020 at 8:31 PM wrote: > > One way to distinguish between type A[N] E and type A [N]E is to be more > space-sensitive and, for example, disallow whitespace between a type name and > the opening square bracket when it signifies type parameters. I would be extremely reluctant to

Re: [go-nuts] Re: Generics and parentheses

On Tue, Jul 14, 2020 at 7:45 PM Watson Ladd wrote: > > Guillamets are worth consideration. They are common on European keyboards and > avoid all the syntax ambiguities. https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use Ian -- You received

[go-nuts] Re: Generics and parentheses

One way to distinguish between type A[N] E and type A [N]E is to be more space-sensitive and, for example, disallow whitespace between a type name and the opening square bracket when it signifies type parameters. Dňa utorok, 14. júla 2020 23:56:01 UTC+2 gri napísal(a): > > We have received a

[go-nuts] Re: Generics and parentheses

This feels a little better, but honestly I'm still all for angle brackets or like Watson suggested, guillamets. *fn(T1)(fn2(T2)(fn3(T3)(v))) // 1fn[T1](fn2[T2](fn3[T3](v))) // 2fn(fn2(fn3(v))) // 3fn«T1»(fn2«T2»(fn3«T3»v))) // 4* To me, with a background in C++ and Typescript and a little

Re: [go-nuts] Generics and parentheses

On Jul 14, 2020, at 5:54 PM, 'Robert Griesemer' via golang-nuts wrote: > > But if we are comfortable with the extra type keyword, the ambiguity > disappears: > > type A[type N] E > > (When we originally dismissed square brackets, the type keyword was not yet > on the table.) > >

[go-nuts] Re: Generics and parentheses

Guillamets are worth consideration. They are common on European keyboards and avoid all the syntax ambiguities. While a technical violation of compatibility by adding new reserved characters, in practice I doubt this will be an issue given the semantics of guillamets. Sincerely, Watson --

[go-nuts] Re: Generics and parentheses

The square bracket-based syntax feels much more readable to me, so it's a welcome change! Based on my dev background I'm still partial to angle brackets and had an idea for disambiguating function calls. We could put the type information as the first data *inside* the parens, so a generic

Re: [go-nuts] Re: Quick question about calling Set-Cookie twice in a row

The Go http code calls Header.Add() on your cookie, and Header.Add will concatenate values together. If you want replacement semantics, you'll have to clearout the "Set-Cookie" header on the response, or only add your final cookie. On Tue, Jul 14, 2020 at 4:58 PM B Carr wrote: > In my

[go-nuts] Re: Quick question about calling Set-Cookie twice in a row

In my application, the most recent cookie value with the same name is returned on the next request. On Tuesday, July 14, 2020 at 1:54:56 PM UTC-6, atd...@gmail.com wrote: > > Hello, > > As I am writing some tests, I was wondering what should be the correct > behavior when http.SetCookie is

[go-nuts] Help Wanted: Implement seek support in FLAC library

Hi all, if you or someone you know is interested in tinkering with audio decoding, please take a look at this issue: https://github.com/mewkiz/flac/issues/16 Partial seek support may be available here: https://github.com/mewkiz/flac/tree/seek -- You received this message because you are

Re: [go-nuts] Generics and parentheses

Hello, > A typical computer keyboard provides four easily accessible pairs of > single-character symmetrical "brackets": parentheses ( and ), square > brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses > curly braces to delineate code blocks, composite literals, and some

[go-nuts] Re: Generics and parentheses

Correction: The last paragraph in the post below should have said: "In Go, type information is not available at *parse* time". (Of course, type information is available at compile time.) On Tuesday, July 14, 2020 at 2:56:01 PM UTC-7 gri wrote: > We have received a variety of feedback on the

[go-nuts] Generics and parentheses

We have received a variety of feedback on the generics draft design (blog ). Thanks to everyone who took the time to read it, play with generics code in the

[go-nuts] Quick question about calling Set-Cookie twice in a row

Hello, As I am writing some tests, I was wondering what should be the correct behavior when http.SetCookie is called twice with cookies of a same name but different values. For example, what should a user-agent see as the cookie value and hence, what should it return back to the server with

[go-nuts] [security] Go 1.14.5 and Go 1.13.13 are released

Hi gophers, We have just released Go 1.14.5 and Go 1.13.13 to address two recently reported security issues. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.14.5). - Data race in certain net/http servers including ReverseProxy Servers

[go-nuts] [security] Go 1.14.5 and Go 1.13.13 are released

Hi gophers, We have just released Go 1.14.5 and Go 1.13.13 to address two recently reported security issues. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.14.5). - Data race in certain net/http servers including ReverseProxy

Re: [go-nuts] Re: golang time.Now().Format with milliseconds without dot in string

I agree, it seems like an unfortunate oversight. You can do it without the slice tricks: https://play.golang.org/p/tNAPOcQqApN It does take an additional Sprintf() though. On Tuesday, July 14, 2020 at 8:40:18 AM UTC-4, Vasiliy Tolstov wrote: > > вт, 14 июл. 2020 г. в 15:17, Jake Montgomery >:

[go-nuts] Considering dropping GO386=387

Hi everyone. We’re exploring the possibility of dropping 387 floating-point support and requiring SSE2 support for GOARCH=386 in the native gc compiler, potentially in Go 1.16. This would raise the minimum GOARCH=386 requirement to the Intel Pentium 4 (released in 2000) or AMD Opteron/Athlon 64

Re: [go-nuts] Re: golang time.Now().Format with milliseconds without dot in string

вт, 14 июл. 2020 г. в 15:17, Jake Montgomery : > > Why not just remove the dot? You know where it is: > https://play.golang.org/p/ZHqHTOeA7HQ > Perhaps there is a better way, but this seems to work. > Yes, thanks. My question mostly - why format time to some intermediate string that needs to be

[go-nuts] Re: golang time.Now().Format with milliseconds without dot in string

Why not just remove the dot? You know where it is: https://play.golang.org/p/ZHqHTOeA7HQ Perhaps there is a better way, but this seems to work. On Tuesday, July 14, 2020 at 7:00:02 AM UTC-4, Vasiliy Tolstov wrote: > > Hi! I'm read several times godoc about the time package but have now > way

[go-nuts] golang time.Now().Format with milliseconds without dot in string

Hi! I'm read several times godoc about the time package but have now way to deal with it. I need to output strings with format MMDDHHMMSSMILLISEC without dot in string. But go able to output milliseconds only in case of .000 -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- You received

Re: [go-nuts] [generics] Type embedding in generic types

Issue openned in https://github.com/golang/go/issues/40199. Still clarifying my thoughts on embedding types within generics, will postpone this debate while I focus on other parts of the proposal and gain some more experience using the go2 branch. Not calling for any action here at this point.