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:
> >
>
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
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
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
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
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
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.
> >
>
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
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
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.
>
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
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#,
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
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
...@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
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
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
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"
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
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
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
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
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
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
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.
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
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
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
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 XGenericFunction(x X) …
>
> пятница, 17 июля 2020 г. в 01:25:29 UTC+3, kortschak:
>> On Thu, 2020-07-16 at 13:44 -0700, jpap wrote:
>>
func XGenericFunction(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
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
>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
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
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
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 ]]
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
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
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
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:
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
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 };
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
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
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
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
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
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
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
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
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
}
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
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
> >
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
>
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
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
55 matches
Mail list logo
