[go-nuts] Re: Generics and parentheses

watso...@gmail.com schrieb am Mittwoch, 15. Juli 2020 um 04:44:53 UTC+2: > Guillamets are worth consideration. They are common on European keyboards > and avoid all the syntax ambiguities. > > > They are common in the french-speaking part of europe. Even the OPs statement > A typical computer k

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

You can use ... As a generic Chinese 你可以使用 ... 作为泛型标志 在2020年8月26日星期三 UTC+8 上午4:59:41 写道： > Thanks for the note. Please see the discussion at > https://groups.google.com/d/msg/golang-nuts/iAD0NBz3DYw/VcXSK55XAwAJ . > > Ian > > On Tue, Aug 25, 2020 at 1:21 PM Kaveh Shahbazian > wrote: > > > >

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

Thanks for the note. Please see the discussion at https://groups.google.com/d/msg/golang-nuts/iAD0NBz3DYw/VcXSK55XAwAJ . Ian On Tue, Aug 25, 2020 at 1:21 PM Kaveh Shahbazian wrote: > > After playing in generics playground with a dozen of cases that came to my > mind, IMHO brackets seem to be m

[go-nuts] Re: Generics and parentheses

After playing in generics playground with a dozen of cases that came to my mind, IMHO brackets seem to be more clear than parentheses for declaring type parameters. Also using the type keyword before the type parameter reduces the cognitive load drastically. type StateFn[type T] func(T) StateFn

[go-nuts] Re: Generics and parentheses

JMTCW: I think using square brackets [...] instead of parenthesis (...) is a good decision. And as someone whose programming experience has not been in C++ or Java, I always found angle brackets for generics to be rather confusing but do not find square brackets as confusing. So in my mind,

[go-nuts] Re: Generics and parentheses

Presumably the instantiation of generic types and functions will be a lot more common than the declarations. How does your proposal handle those? (FWIW, I'm fine with square brackets, or really anything other than parens.) On Monday, July 20, 2020 at 12:42:13 PM UTC-4 Geoff Speicher wrote: > Th

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

Thanks for the feedback Ian! I was drawing the idea mostly from Rust, which already does the same thing, but uses "::" instead of a dot and it works fine there, but sure, it has its drawbacks. st 22. 7. 2020 o 0:05 Ian Lance Taylor napísal(a): > On Tue, Jul 21, 2020 at 8:49 AM wrote: > > > > I

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

On Tue, Jul 21, 2020 at 8:49 AM wrote: > > I feel like you guys missed my suggestion earlier. I will repeat it because I > think it can be good. What about a dot to separate type parameters in > specialization? > > func zero() T { > var x T > return x > } > > func mai

[go-nuts] Re: Generics and parentheses

I feel like you guys missed my suggestion earlier. I will repeat it because I think it can be good. What about a dot to separate type parameters in specialization? func zero() T { var x T return x } func main() { fmt.Println(zero.()) // . required here }

[go-nuts] Re: Generics and parentheses

On Tuesday, 21 July 2020 05:06:11 UTC+2, Bit0r Mack wrote: > > > Among them, is the most convenient to input, > because < and? Are very close on the keyboard, so you can input quickly > < and ? on my keyboard are almost the most distant keys (_ and ° having the same distance and < and ^ being t

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

On Wednesday, July 15, 2020 at 6:41:51 AM UTC-6 Michal Strba wrote: > What about using a dot when specializing in bodies? > > func main() { > x := zero.() // requires a dot > } > What are all the kinds of "generic expressions" we would need to support? Go allows incomplete floati

[go-nuts] Re: Generics and parentheses

I think you can use <:T:> or <<>> or . Among them, is the most convenient to input, because < and? Are very close on the keyboard, so you can input quickly gri在 2020年7月15日星期三上午5:56:01 [UTC+8]寫道： > We have received a variety of feedback on the generics draft design >

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

On Mon, Jul 20, 2020 at 12:26 PM Geoff Speicher wrote: > > On Mon, Jul 20, 2020 at 2:04 PM Ian Lance Taylor wrote: >> >> On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher wrote: >> > >> > This is great work but compared to the rest of Go's existing syntax, I >> > personally find it much harder to

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

On Mon, Jul 20, 2020 at 2:04 PM Ian Lance Taylor wrote: > On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher wrote: > > > > This is great work but compared to the rest of Go's existing syntax, I > personally find it much harder to grok the generic code examples regardless > of bracket choice. > > >

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

On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher wrote: > > This is great work but compared to the rest of Go's existing syntax, I > personally find it much harder to grok the generic code examples regardless > of bracket choice. > > It seems like a lot of complication stems from what effectively

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

On Mon, Jul 20, 2020 at 9:41 AM Rei Roldan wrote: > > I agree, I prefer the D syntax as well. > > type!T Point struct { > x, y int > data !T > } > > type Transformer interface { > Transform(!R) !S > } > > func Stringify(s []!T) string { > } > > type Vector []!T > > Easy and readable :)

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

On Mon, Jul 20, 2020 at 7:22 AM christoph...@gmail.com wrote: > > I would like to insist on considering the D syntax using the ! for generics > instantiation. > > The first time I saw it, I was puzzled and found it unpleasant. But this is > just because it is unfamiliar and not intuitive. > Once

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

On Mon, Jul 20, 2020 at 1:23 AM Xie Zhenye wrote: > > Requiring type-information for parsing will brings difficulty for > implementing these tools, but not impossible. To solve ambiguity, the only > requiring type-information is wether a symbol is a type name or an > identifier. A parser packag

[go-nuts] Re: Generics and parentheses

This is great work but compared to the rest of Go's existing syntax, I personally find it much harder to grok the generic code examples regardless of bracket choice. It seems like a lot of complication stems from what effectively amounts to requiring the programmer to declare a new generic type

[go-nuts] Re: Generics and parentheses

I agree, I prefer the D syntax as well. *type!T Point struct {* *x, y int* *data !T* *}* *type Transformer interface {* *Transform(!R) !S* *}* *func Stringify(s []!T) string {* *}* *type Vector []!T* Easy and readable :) On Monday, 20 July 2020 at 16:22:08 UTC+2 christoph...@gmail

[go-nuts] Re: Generics and parentheses

I would like to insist on considering the D syntax using the ! for generics instantiation. The first time I saw it, I was puzzled and found it unpleasant. But this is just because it is unfamiliar and not intuitive. Once I got used to it, I found it much simple than the C++ templates. In fact

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

Requiring type-information for parsing will brings difficulty for implementing these tools, but not impossible. To solve ambiguity, the only requiring type-information is wether a symbol is a type name or an identifier. A parser package can help this.Since other languages like Java, C#, TypeSc

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

On Mon, Jul 20, 2020 at 8:33 AM Xie Zhenye wrote: > Gramma of a programming language is not able to be changed after released. > So language design is elegant or not is more important than difficulty of > implementing. > > Adding type information in parse time and use angle brackets only affects

[go-nuts] Re: Generics and parentheses

Gramma of a programming language is not able to be changed after released. So language design is elegant or not is more important than difficulty of implementing. Adding type information in parse time and use angle brackets only affects compiler and 3rd part tools or IDEs in a short time. Prov

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

None of my laptops have guillamets on them, so that's pretty much dead on arrival On Friday, July 17, 2020 at 5:56:32 PM UTC+2, Jon Conradt wrote: > > In the spirit of “show me, don’t tell me” and experience reports. How hard > would it be to release a beta which supports both [] and guillamets?

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

...@theconradts.com Https://go.theconradts.com/patents From: Yaw Boakye Sent: Saturday, July 18, 2020 10:43:11 AM To: Jon Conradt Cc: golang-nuts Subject: Re: [go-nuts] Re: Generics and parentheses I don't know if the recommendation to use guillamets is out of spite fo

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

I'm glad that the use of ( and ) is being reconsidered as I found their use made *reading* source code with generics more difficult (albeit whilst making parsing easier). One of the features of Go I really like is how readable the source code is and every effort should be made to maintain this

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

I don't know if the recommendation to use guillamets is out of spite for the ongoing deliberations. But if it's a serious recommendation, then can some recommend where I can buy one of these European keyboards? On top of that, I could start a business selling European keyboards to Go programmers in

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

On Sat, Jul 18, 2020 at 11:44 AM Mariusz Gronczewski wrote: > pipe character isn't exactly used anywhere in Go, is on every keyboard and > looks decent enough: It's the bitwise binary or operator. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group

[go-nuts] Re: Generics and parentheses

Hi pipe character isn't exactly used anywhere in Go, is on every keyboard and looks decent enough: a, b = w | x, y | (z) type Example |X, Y| struct { } certainly not worse than square brackets with having advantage of not being ambiguous to newbies or parser -- You received this message

[go-nuts] Re: Generics and parentheses

The square bracket has a bit of history in go already, as a key-type specifier for the somwhat generics-like map declaration; since we already do var map[int]string it feels a bit natural to specify types in square brackets to me. -- You received this message because you are subscribed to t

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

On Sat, Jul 18, 2020 at 7:22 AM Steve Ruble wrote: > Consider: > > a, b = w < x ; y > (z) That requires an unbound lookahead which is better avoided. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop recei

[go-nuts] Re: Generics and parentheses

Rather than resolving the potential ambiguities of < and > by using different symbols, could we use an unambiguous delimiter between the type parameters instead? Consider: a, b = w < x ; y > (z) The use of ; is not much harder to read or type than , and I think < and > are so close to being

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

How would you deal if you use `-generics {` but your imported library uses `[`? On Friday, July 17, 2020 at 3:56:39 PM UTC-7 rise...@gmail.com wrote: > How about a "-generics" compile flag that lets you select one pair from a > character set of [ ( { < « . > > On Friday, July 17, 2020 at 8:56:3

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

On Fri, 2020-07-17 at 15:56 -0700, Jay Kay wrote: > How about a "-generics" compile flag that lets you select one pair > from a character set of [ ( { < « . This hits two of the things that Go doesn't do: 1. proliferation of compiler option flags 2. enabling dialect spliting -- You recei

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

How about a "-generics" compile flag that lets you select one pair from a character set of [ ( { < « . On Friday, July 17, 2020 at 8:56:32 AM UTC-7 Jon Conradt wrote: > In the spirit of “show me, don’t tell me” and experience reports. How hard > would it be to release a beta which supports both

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

Perhaps many would think this is "too complicated" but I like the idea of supporting 2 syntaxes, one of which is the output of gofmt. *func Print(type T)(s []T) * >> gofmt >> *func Print«T»(s []T)* This way nobody is required to type it right the first time, but everybody can read the code bet

[go-nuts] Re: Generics and parentheses

Brackets avoid ambiguity, and allows the developer to concentrate on what the code is doing rather than trying to interpret it. On Tuesday, July 14, 2020 at 5:56:01 PM UTC-4 gri wrote: > We have received a variety of feedback on the generics draft design >

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

On Fri, Jul 17, 2020 at 8:28 AM Dominique Devienne wrote: > > On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 gri wrote: >> >> Not unexpectedly, many people raised concerns about the syntax, specifically >> the choice of parentheses for type parameter declarations and generic type >> and function

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

As others have mentioned, I'm still partial to angles to represent generics. e.g. func Method(input Type) I'm really glad you didn't go the round bracket method as that's super confusing in a method declaration. Squares aren't horrible, but I've always associated them with indexing/key lookups.

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

Jon, this is a special case where a "tr '«»' '[]'' is enough. On Fri, Jul 17, 2020 at 8:56 AM Jon Conradt wrote: > In the spirit of “show me, don’t tell me” and experience reports. How hard > would it be to release a beta which supports both [] and guillamets? We try > them. We see where we have

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

In the spirit of “show me, don’t tell me” and experience reports. How hard would it be to release a beta which supports both [] and guillamets? We try them. We see where we have compatibility problems. We give editor writers and plugin writers a chance to simplify they keystrokes? Jon On Tuesd

[go-nuts] Re: Generics and parentheses

On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 gri wrote: > Not unexpectedly, many people raised concerns about the syntax, > specifically the choice of parentheses for type parameter declarations and > generic type and function instantiations. > Nobody mentioned D's generics? https://dlang.org

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

Since readability is impacted by consequitive lists, you could factor it out... with ( type list ) func ( arg list ) etc... -- 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 a

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

Best proposal yet! I see increased Go adoption in the hipster /craft beer community. > On Jul 16, 2020, at 6:49 PM, Denis Cheremisov > wrote: > > func 🍺X🍺GenericFunction(x X) … > > пятница, 17 июля 2020 г. в 01:25:29 UTC+3, kortschak: >> On Thu, 2020-07-16 at 13:44 -0700, jpap wrote: >> >

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

func 🍺X🍺GenericFunction(x X) … пятница, 17 июля 2020 г. в 01:25:29 UTC+3, kortschak: > On Thu, 2020-07-16 at 13:44 -0700, jpap wrote: > > Notwithstanding a concise unambiguous alternative, I would rather > > type parameters "stick out" so they are easily identified when > > visually scanning thr

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

On Thu, 2020-07-16 at 13:44 -0700, jpap wrote: > Notwithstanding a concise unambiguous alternative, I would rather > type parameters "stick out" so they are easily identified when > visually scanning through code. func ᕙ(⇀ X ↼‶)ᕗ GenericFunction(x X) ... -- You received this message because you

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

>I can accept draft as is I've changed my mind about my suggestion. I can also accept and fully support draft as is! It is fantastic. On Fri, Jul 17, 2020 at 12:10 AM Matthias Mädel < medienwerksalzb...@gmail.com> wrote: > Just some considerations... > > Generics syntax is a constraint of the

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

Just some considerations... Generics syntax is a constraint of the Parser Gen ops used with dB/ML/wire stuff... Encapsulating parantheses follow logic The type keyword shows the functionality square brackets introduce a, not only visual, distraction/confusion I can accept draft as is -- You

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

On Thu, Jul 16, 2020 at 11:50 PM burak serdar wrote: > > [_ _] is ambiguous though, because _ is also an identifier character. > [_x_] can be parsed as indexing with identifier _x_ > Yes, _int_ is an allowed identifier in Go. However per the suggestion at the top of the present thread the compi

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

On Thu, Jul 16, 2020 at 3:43 PM Robert Viragh wrote: > > Hi guys, > > Great conversation! I think that seeing a lot of edge cases would make it > easiest to see what is best. > > Since the conversation went into [[ and ]] > > Before coming up with [_ and _] I very strongly considered [[ and ]] be

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

Hi guys, Great conversation! I think that seeing a lot of edge cases would make it easiest to see what is best. *Since the conversation went into [[ and ]]* Before coming up with [_ and _] I very strongly considered [[ and ]] because I thought things should be orthogonal and different things sho

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

On Thursday, 16 July 2020 at 22:44:21 UTC+2 jpap wrote: > I don't think [[T]] is offensive to the surrounding code, and would love > to know what more people think. > It becomes even worse once you nest generic types: MyMap[[string, MyList[[int -- You received this message because y

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

Notwithstanding a concise unambiguous alternative, I would rather type parameters "stick out" so they are easily identified when visually scanning through code. I read a lot more code than I write, even as I write Go full-time. Here are two playgrounds (that don't format/run) comparing a gener

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

Generics are not the most important part of the language/code. Let's not make them stick out like a sore thumb. On Thursday, 16 July 2020 at 22:12:17 UTC+2 jpap wrote: > On Thursday, 16 July 2020 at 12:51:03 UTC-7 Ian Lance Taylor wrote: > >> On Thu, Jul 16, 2020 at 12:41 PM joshua harr wrote:

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

On Thursday, 16 July 2020 at 12:51:03 UTC-7 Ian Lance Taylor wrote: > On Thu, Jul 16, 2020 at 12:41 PM joshua harr wrote: > > Just a note on your rationale for why not to use <: :> : > > "... requires more typing." Golang has, rather famously, never shied > away from making developers type mor

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

Why not have a github emoji vote. 1. () `type MyMap(K comparable, V something) struct { m map[k]v }; fn(int, float)(4, .20);` 2. [] `type MyMap[K comparable, V something] struct { m map[k]v }; fn[int, float](4, .20);` 3. <::> `type MyMap<:K comparable, V something:> struct { m map[k]v }; fn<:int,f

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

On Thu, Jul 16, 2020 at 12:41 PM joshua harr wrote: > > Just a note on your rationale for why not to use <: :> : > "... requires more typing." Golang has, rather famously, never shied away > from making developers type more. The reason it hasn't, as far as I > understand, is that code is read fa

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

Just a note on your rationale for why not to use <: :> : "... requires more typing." Golang has, rather famously, never shied away from making developers type more. The reason it hasn't, as far as I understand, is that code is read far often than it is written, and so the extra verbosity is wort

[go-nuts] Re: Generics and parentheses

`generics` looks like a space , like c++ namespace/classSpace use `::` `.` `->` and `::` is not used in golang. ``` type A::(x,y,z) struct{ } func f::(x,y,z)()(){} interface B::(x,y,z)()(){} []S::(x,y,z){} ``` `FOO::(x,y,z)` just like a `string` for naming . and the args x,y,z ar

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

Its worth noting that Rust does something similar with the "turbofish" operator in expressions: "42".parse::() I personally think this works quite well. On Wednesday, July 15, 2020 at 5:41:51 AM UTC-7, Michal Strba wrote: > > Angle brackets are only problematic in expressions in the bodies of

[go-nuts] Re: Generics and parentheses

Proposals that employ the type keyword, look more Go-ish. Go is already doing many things differently than other PLs in C-ish family - the if without parentheses and no semicolon are two of things that hit most when switching frequently between Go and another PL. func SomeContext() { var aS

[go-nuts] Re: Generics and parentheses

Hi, Why do we have to allow people to write something like `w(z)` or `w(x,y)(z)` or `w[x,y](z)`? It's not "go-style" stuff. Something more in "go-style" should be: ``` wxy := w a, b = wxy(z) ``` It is much more clear and elegant, just like what we have for error handling. In this way, brac

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

On Wed, Jul 15, 2020 at 7:59 AM kaleidawave wrote: > > Correct me if I am wrong but wouldn't square bracket syntax have an ambiguity > around calling a function pointer at a position in a slice: > > z := []func() int{x, y}; > a := z[0](); A parsing ambiguity arises when the same code can be pars

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

On Wed, Jul 15, 2020 at 7:59 AM jpap wrote: > > Two thoughts: > > 1. How useful is it in practice to have separate start and end delimiters? > Does it matter for nested declarations? I didn't see any nested declarations > in the Draft Design document, for example. If allow the same token on b

[go-nuts] Re: Generics and parentheses

I really like this square bracket syntax and I'm glad that Go does not repeat the mistakes other languages have made.. -- 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 emai

[go-nuts] Re: Generics and parentheses

Dear Developers: You have spent several years on this and I'm impressed by the result, it looks beautiful! I'm stunned. As you can see from the recent spotlight shown on this syntax, in the meanwhile people have resorted to using unicode characters that sort of look like delimiters but are ju

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

I'm in favor of the square brackets. scala has them as well so we're not exactly blazing a new trail. I'm not in favor of a second `type` keyword whose benefit is to disambiguate syntax to the parser. we already use significant whitespace to identify tokens. for example, we expect to be parsing a f

[go-nuts] Re: Generics and parentheses

Square brackets feel much better. It removes a lot of ambiguity in reading code. Actually I personally wouldn't mind to have double square brackets as "Generics" indicator just to remove also what little reading ambiguity they can cause with indices. type A[[N]] E On Tuesday, July 14, 2020

[go-nuts] Re: Generics and parentheses

Here's my 2cents: I actually don't mind the parenthesis.. I've written a bunch of functions with them now ( https://github.com/DylanMeeus/hasgo2/tree/master/functions) and they become readable quickly. (Although I also enjoy LISP flavours, so maybe that biases my view of parenthesis :D) But a

[go-nuts] Re: Generics and parentheses

Two thoughts: 1. How useful is it in practice to have separate start and end delimiters? Does it matter for nested declarations? I didn't see any nested declarations in the Draft Design document , f

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

Go code use a Syntax analog to casting instead of the type keyword. f.[int](args) or var x map[string]GType.[int] That does not collide with other language features in function declaration, type definitions, inner types in structs or interfaces, variable declarations, type alias declarations an

[go-nuts] Re: Generics and parentheses

Correct me if I am wrong but wouldn't square bracket syntax have an ambiguity around calling a function pointer at a position in a slice: z := []func() int{x, y}; a := z[0](); https://play.golang.org/p/lekFJlvbRTD On Tuesday, July 14, 2020 at 10:56:01 PM UTC+1 gri wrote: > We have received a va

[go-nuts] Re: Generics and parentheses

Hello all, I'd first like to say thanks to the go team for their incredible work on delivering such a usable tool as go. I will then proceed to bring my 2 cents to the World Bikeshedding Foundation :) I would add a vote to have something more differenciating to indicate "this is a generic ins

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

On Jul 15, 2020, at 12:13 AM, Ian Lance Taylor wrote: > > The disadvantage of guillemets is that they are hard to type on many > keyboards. So to me either square brackets or angle brackets would be > better than guillemets. Not to mention that, while Go *is* officially in UTF-8, the chance of

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

Angle brackets are only problematic in expressions in the bodies of functions when specializing a function or a type, right? They are not problematic in signatures and type definitions. What about using a dot when specializing in bodies? func zero() T { var z T return z }

[go-nuts] Re: Generics and parentheses

Great! Those multiple parenthesis were a beat on unredable side indeed, and I always was in the pro-square party as I always found less and greater signs to be unreadable. As much as I disliked Scala in general I liked their generic syntax. This is a really good news Go will have the same. сред

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

I think square brackets are better than parentheses for several reasons: 1. fewer parser ambiguities (see the post that started this thread) - thus fewer cases where programmers must remember "oh, this is a special case, I must put additional parentheses somewhere" 2. programmers can distinguish

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 > > fn[T

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 > fn«T1»(fn2«T2»(fn3«T3»v

[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 Groups

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 m

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 var

[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 b

[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 funct

[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 gen