jlge...@gmail.com schrieb am Montag, 17. August 2020 um 19:13:45 UTC+2:
>
>- No support covariance or contravariance. Maybe I am on shaky ground
>in terms of my understanding but doesn't this mean, for instance, that if
> I
>have two interfaces, Foo and Bar, and a third composite
On Mon, Aug 17, 2020 at 10:13 AM Jonathan Gerber wrote:
>
> 1) Of the enumerated omissions, the ones that I think are really unfortunate
> are, in order of importance, from my perspective:
>
> No operator methods & no adapters - Doesn't this make generic types sort of
> second class?. I think
> No support covariance or contravariance. Maybe I am on shaky ground in
terms of my understanding but doesn't this mean, for instance, that if I
have two interfaces, Foo and Bar, and a third composite interface, FooBar,
which consists of Foo and Bar, that a function with a generic parameter T
As someone who has spent a LOT of time in Rust, I really miss generics in
Go (Conversely, i miss the simplicity of Go. My personal favorite,
imaginary language would probably be Go + Generics + Sum Types and
destructuring) and so I am really excited to see this taking shape.
That being said,
I am trying to add my 2 cents here.
I am sorry if my opinions have been mentioned.
I personally prefer Round Brackets (parentheses). It is not about
readability on symbols, but the way how I understand the logic of Type
Parameters.
I see Type Parameters as a way to describe how to
> Have the authors considered the implications of requiring the `type`
keyword to use a generic type, not just at declaration time? Would this
open up more syntax possibilities, such as `var x T`? This might
be easier to read at the expense of five more characters of typing. It also
could
On Thu, Aug 6, 2020 at 9:26 PM 'Red Daly' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Have the authors considered the implications of requiring the `type`
> keyword to use a generic type, not just at declaration time? Would this
> open up more syntax possibilities, such as `var x T`?
On Thu, Aug 6, 2020 at 12:25 PM 'Red Daly' via golang-nuts
wrote:
>
> Have the authors considered the implications of requiring the `type` keyword
> to use a generic type, not just at declaration time? Would this open up more
> syntax possibilities, such as `var x T`? This might be easier to
>
Have the authors considered the implications of requiring the `type`
keyword to use a generic type, not just at declaration time? Would this
open up more syntax possibilities, such as `var x T`? This might
be easier to read at the expense of five more characters of typing. It also
could
Hi Russ,
In general, I think the proposal is a really good one. I like that you
abandoned contracts as interfaces were just too similar, and personally I
like the choice of square brackets.
There are a few aspects I do not like — 1.) no zero value and 2.) lack of
covariance and
On Wed, Jul 22, 2020 at 8:02 PM, Russ Cox wrote:
> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
>
> Best,
> Russ
>
I think this thread is specifically about
[ ] is nice. Nim also uses [ ] for generics. --Kent
On Wed, Jul 22, 2020 at 4:41 PM Denis Cheremisov
wrote:
> Lesser and greater signs never were a good choice. They were chosen
> because of C syntax restrictions. Go creators would do *slice[T]* (or may
> be just *[T]*), *map[K,V]*,* chan[T]*,
So it seems! nothing substantive on the hard part.
On Wed, Jul 22, 2020 at 5:02 PM Russ Cox wrote:
> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
>
> Best,
>
On Jul 22, 2020, at 8:02 PM, Russ Cox wrote:
>
> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
We haven't covered what the bike shed roof is going to be made
Very correct! At least from my perspective.
On Thu, 23 Jul 2020 at 02:02 Russ Cox wrote:
> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
>
> Best,
> Russ
>
>
>
On Jul 15, 2020, at 4:59 PM, Ian Lance Taylor wrote:
>
> On Wed, Jul 15, 2020 at 5:44 AM Jan Mercl <0xj...@gmail.com> wrote:
>>
>> My 2c - Alternative type parameters syntax (ab)using @$:
>> https://docs.google.com/document/d/1AoU23DcNxYX2vYT20V2K16Jzl7SP9taRRhIT8l_pZss/edit?usp=sharing
>
>
So it sounds like everyone is in favor of the entire generics proposal and
all the semantics, and all we have left to hammer out is the bracket
characters? Do I have that right?
Best,
Russ
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
Lesser and greater signs never were a good choice. They were chosen because
of C syntax restrictions. Go creators would do *slice[T]* (or may be just
*[T]*), *map[K,V]*,* chan[T]*, etc if they had generics in mind. Because,
if you have managed not to notice it, Go barely inherited anything from
With angled brackets, do we really need the colon or dot on both sides?
Wouldn't it be enough to just have it on the left to eliminate the parse
time ambiguities? Like f<:int> or f<.int>?
On Wed, 22 Jul 2020, 22:46 Евгений Кошевой,
wrote:
> Maybe something like this:
> using <.Type.>
> func
Maybe something like this:
using <.Type.>
func f(T<.int.>)
struct{ T<.int.> }
interface{ T<.int.> }
[]T<.int.>{}
среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop:
> On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba wrote:
>
>> I'd say a dot is necessary when instantiating a function call
On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba wrote:
> I'd say a dot is necessary when instantiating a function call but
> unnecessary when instantiating a type because it's always syntactically
> clear when a type is required.
>
That's not true in Go. Conversions look like function calls:
I'd say a dot is necessary when instantiating a function call but
unnecessary when instantiating a type because it's always syntactically
clear when a type is required.
ut 21. 7. 2020 o 18:51 napísal(a):
> Using angle brackets is not a must for supporting generics, but it is the
> common syntax
like java？i like it
在 2020年7月15日星期三 UTC+8上午6:31:55，Harald Weidner写道：
>
> 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 <
Using angle brackets is not a must for supporting generics, but it is the
common syntax of generics in programming languages that support generics, the
same way as square brackets are the common syntax for indexing in programming
languages.
If I understand correctly, the ambiguity problem with
This seems to be very similar to a suggestion I made a couple of years ago:
https://gist.github.com/peter-mckenzie/5cc6530da1d966e743f4a39c150a6ac2
The spaces are in different places but that could be regarded as a matter
of style.
I always liked it, but maybe a little too quirky for most :-)
Not that I am for guillemets, but isn't attempting to push the industry towards
a richer pallette than ASCII the whole point of building unicode into the core
of go? We already include the middot in go assembly, and some core members of
the go team love using unicode identifiers in personal
The more I think about this suggestion, the more I like it.
- It solves the lookahead problem (I think);
- it visually separates the type parameters from the actual parameters and
return types, so the choice of delimiter characters for the type arguments
becomes less relevant from a
>
Sent: Saturday, July 18, 2020 10:43:11 AM
To: Jon Conradt mailto:j...@theconradts.com>>
Cc: golang-nuts
mailto:golang-nuts@googlegroups.com>>
Subject: Re: [go-nuts] Re: Generics and parentheses
I don't know if the recommendation to use guillamets is out of spite for the
ongo
Older thread:
https://groups.google.com/u/0/g/golang-nuts/c/zGQq_I5r2jg/m/_LPQDf3BBgAJ
And the poll: https://www.surveylegend.com/s/2dwe
On Saturday, July 18, 2020 at 11:58:50 p.m. UTC+7 golde...@gmail.com wrote:
> Can not agree any more. Compiler's job, it's duty, is to translate the
> human
Can not agree any more. Compiler's job, it's duty, is to translate the
human readable code into binary 0 and 1. Human readability should take
precedence over the compiler complexity and even performance.
在 2020年7月15日星期三 UTC+8下午12:45:41，robert engels写道：
>
> My opinion is that every major
On Sat, 18 Jul 2020, 13:25 Jan Mercl, <0xj...@gmail.com> wrote:
> On Sat, Jul 18, 2020 at 1:39 PM roger peppe wrote:
>
> > I didn't say there was exactly one construct for each kind of name
> definition. In current Go, when a name is defined, it's defined inside a
> construct that is explicitly
On Sat, Jul 18, 2020 at 1:39 PM roger peppe wrote:
> I didn't say there was exactly one construct for each kind of name
> definition. In current Go, when a name is defined, it's defined inside a
> construct that is explicitly about defining that name. By contrast, in your
> proposal, we take
On Sat, 18 Jul 2020 at 11:05, Jan Mercl <0xj...@gmail.com> wrote:
> On Sat, Jul 18, 2020 at 11:12 AM roger peppe wrote:
>
> Thanks for taking time to think about it.
>
> > A few reasons that I'm not keen on your $, @ proposal:
> >
> > - elsewhere in Go, when a name is defined, there is one clear
On Sat, Jul 18, 2020 at 12:12 PM roger peppe wrote:
>
> - elsewhere in Go, when a name is defined, there is one clear construct
>> that defines it, not an arbitrary place within a type expression. That's
>> not the case in your proposal.
>>
>
On the other hand, $/@ is not dissimilar to using the
On Sat, Jul 18, 2020 at 11:12 AM roger peppe wrote:
Thanks for taking time to think about it.
> A few reasons that I'm not keen on your $, @ proposal:
>
> - elsewhere in Go, when a name is defined, there is one clear construct that
> defines it, not an arbitrary place within a type expression.
On Thu, 16 Jul 2020, 14:38 Jan Mercl, <0xj...@gmail.com> wrote:
> On Thu, Jul 16, 2020 at 3:12 PM 'Axel Wagner' via golang-nuts
> wrote:
>
> > I dislike the idea of using $ and @ because I don't want to add new
> symbols to the language, if it can be avoided. In general I'd argue that Go
> tends
Why not try the design of Feel language,
There is no ambiguity and no more code.
```
type [Item T] struct {
Value T
}
func (it [Item T]) Print() {
println(it.Value)
}
func [TestGenerics T V]() {
var a = [Item T]{}
a.Print()
var b = [Item V]{}
On Thu, Jul 16, 2020 at 3:12 PM 'Axel Wagner' via golang-nuts
wrote:
> I dislike the idea of using $ and @ because I don't want to add new symbols
> to the language, if it can be avoided. In general I'd argue that Go tends to
> use keywords instead of symbols to convey meaning - e.g. we don't
I dislike the idea of using $ and @ because I don't want to add new symbols
to the language, if it can be avoided. In general I'd argue that Go tends
to use keywords instead of symbols to convey meaning - e.g. we don't write
`a -> b`, but `func(a) b`. There are exceptions (pointers are a big one)
This is good. I have been reaching for a consistency check and this just
may be it.
On Thu, Jul 16, 2020 at 12:04 AM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote:
> > And the use of [ ] in map is more
On Wed, 2020-07-15 at 18:09 -0700, lotus.developer.mas...@gmail.com
wrote:
> Personally think this way is easier to read. In this way, I wrote a
> few examples, which may be different from the creator
Please post in unstyled plain text. It is almost impossible to read the
code examples you have
Personally think this way is easier to read. In this way, I wrote a few
examples, which may be different from the creator
* For example: define a node
type Node struct{
prev *Node
data T //data *T
next *Node
}
* Call request
var node Node
* Let's take another example, such as the
Perhaps another source of resistance to < > is the trauma many of us have from
its major obfuscation of C++ code?
- Randy
> On Jul 15, 2020, at 3:13 PM, Yaw Boakye wrote:
>
> To summarize the thread so far:
>
> - parenthesis is a no-no
> - angle brackets are popular/common but that alone
The big argument I always found less and greater signs to be not visually
distinctive enough, at least with fonts I am using. [ and ] are larger and
I was really happy with them in Scala although I dislike the language in
general.
Seriously though, the real big argument is [] are already used
On Wed, Jul 15, 2020 at 3:27 PM Bakul Shah wrote:
>
> The syntax rule I envisioned was this:
> type: ... | type generic-type | ...
>
> To me, using full parenthesization, this would be
> func() int pair pair" == "((func() int) pair)pair --(1)
> What you seem to want is
> (func() (int pair)) pair
On Wed, 2020-07-15 at 15:27 -0700, Bakul Shah wrote:
> The second issue is the usage for generic functions. Contrast
>
> (float64, int)PowN(1.2, 3)
> with
> PowN[float64, int](1.2, 3)
> or currently
> PowN(float64, int)(1.2, 3)
>
> I find the alternate syntax easier because
> On Jul 15, 2020, at 1:49 PM, Ian Lance Taylor wrote:
>
> On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah wrote:
>>
>> I don't much like square brackets or angle brackets or guillemets. But here
>> is a different way
>> of reducing the need for parentheses at least for the common case:
>>
>>
On Wed, 2020-07-15 at 17:10 -0500, Seebs wrote:
> That said, if people don't like square brackets, I'm totally prepared
> to make worse suggestions until they give up and say square brackets
> aren't that bad.
>
Let's bring back the special five keywords!
func despiteallobjections F insofaras
To summarize the thread so far:
- parenthesis is a no-no
- angle brackets are popular/common but that alone doesn't make good
argument. some languages have already deviated. scala is popular, uses
square instead of angle brackets.
- go's current pseudo-generic data structure, the map, already
On Wed, 15 Jul 2020 14:51:17 -0700
jimmy frasche wrote:
> I didn't care about () except for having to then have extra parens
> around types in a lot of places which was very annoying and came up
> often. If [] fixes that, great!
I was pretty unhappy with () just because there's too many () and
On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote:
> And the use of [ ] in map is more semantically associated with its
> conventional use as an element accessor in arrays / slices, not with
> some more general kind of type parameter.
The [] syntax can be viewed as an indexing operation
I didn't care about () except for having to then have extra parens
around types in a lot of places which was very annoying and came up
often. If [] fixes that, great!
On Wed, Jul 15, 2020 at 2:47 PM Ian Lance Taylor wrote:
>
> On Wed, Jul 15, 2020 at 2:36 PM Randall O'Reilly wrote:
> >
> >
On Wed, Jul 15, 2020 at 2:36 PM Randall O'Reilly wrote:
>
> Regarding the parsing: as I suggested in my email, but perhaps was unclear,
> in case of two conflicting *purely syntactic* interpretations (without using
> any type information), you could just choose the more high-frequency
>
This is what I was thinking. Format for the common case. At compile/link time
you would be able to figure out the conflict and throw an error and the dev
could add the parens to make it unambiguous.
> On Jul 15, 2020, at 4:36 PM, Randall O'Reilly wrote:
>
> Regarding the parsing: as I
Regarding the parsing: as I suggested in my email, but perhaps was unclear, in
case of two conflicting *purely syntactic* interpretations (without using any
type information), you could just choose the more high-frequency interpretation
(i.e., type parameters) and force the programmer to use
But Scala doesn’t use [] for anything else - Go does.
> On Jul 15, 2020, at 9:58 AM, 'Nic Long' via golang-nuts
> wrote:
>
> Square brackets work great. Scala uses them for generics to great effect.
> They also make me think of Clojure, which introduced them to Lisp for similar
> reasons
On Wed, Jul 15, 2020 at 5:44 AM Jan Mercl <0xj...@gmail.com> wrote:
>
> My 2c - Alternative type parameters syntax (ab)using @$:
> https://docs.google.com/document/d/1AoU23DcNxYX2vYT20V2K16Jzl7SP9taRRhIT8l_pZss/edit?usp=sharing
Thanks for the detailed writeup. I'm a bit concerned about name
On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah wrote:
>
> I don't much like square brackets or angle brackets or guillemets. But here
> is a different way
> of reducing the need for parentheses at least for the common case:
>
> A proposal for fewer irritating parentheses!
>
> One thing to note is
On Jul 15, 2020, at 2:48 PM, Ian Lance Taylor wrote:
>
> More seriously, though, let's look closely at Robert's example:
>
> a, b = w < x, y > (z)
TBH, I think a big argument in favor of square brackets over angle brackets is
that they ascend above the center line in most typefaces, which
On Wed, 15 Jul 2020 12:26:15 -0700
Ian Lance Taylor wrote:
> The suggested syntax, whether with parentheses or square brackets, has
> what I consider to be a very nice property: the definition and use
> syntaxes are very similar. For the definition we write
>
> func F[type T]() {}
>
> For the
On Tue, Jul 14, 2020 at 10:06 PM Paul Johnston wrote:
>
> 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 {
Correction: I think it is much more important that Go remains internally
consistent in its use of "square" brackets.
On Wednesday, July 15, 2020 at 8:54:58 PM UTC+2 Hein Meling wrote:
> When you refer to beginners, I think you mean developers from other
> languages (Java/C#/C++...) that
When you refer to beginners, I think you mean developers from other
languages (Java/C#/C++...) that already know the concept of generics. I
don't think they will have problems adapting to a square brackets
notation... they are smart people, and after all they have to learn many
other
On Tue, Jul 14, 2020 at 9:45 PM robert engels wrote:
>
> 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
>
Agreed. I've been a happy Gopher since 2011 and would really like to see <>
or even [] instead of ().
On Wednesday, 15 July 2020 20:03:40 UTC+3, Dan Markham wrote:
>
> On Tuesday, July 14, 2020 at 9:45:41 PM UTC-7, robert engels wrote:
>>
>> My opinion is that every major language (no flames
On Tuesday, July 14, 2020 at 9:45:41 PM UTC-7, robert engels wrote:
>
> 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
>
On Tue, 14 Jul 2020 23:19:40 -0700 (PDT)
Fino wrote:
> I vote for <: and :>
I'm conflicted on it. <> match what several other languages do, but are
problematic for the parser. () is definitely overused. [] is tolerable.
I'd like to bring up the possibility of ??( and ??), mostly so that
This is similar to C++ template, and it's very clear to understand.
On Wednesday, July 15, 2020 at 1:06:24 PM UTC+8, Paul Johnston wrote:
>
> If the generic expression was always attached/constrained to the
> "type" or "func" keyword (rather than the type or function name), perhaps
> this
Square brackets work great. Scala uses them for generics to great effect.
They also make me think of Clojure, which introduced them to Lisp for
similar reasons to here - to avoid too much overload of regular parentheses
- and which people have been very happy with.
On Wednesday, 15 July 2020
On Jul 15, 2020, at 4:47 AM, Nick Craig-Wood wrote:
>
> In my mind the use of [ ] clashes horribly with the array declaration
> syntax. When I see [int] in particular my brain says, ah array declaration of
> size int, what, no wait...
On the other hand, this is already how maps are declared
On Tue, Jul 14, 2020 at 11:55 PM 'Robert Griesemer' via golang-nuts
wrote:
> The time has come to revisit this early decision. If square brackets alone
> are used to declare type parameters, the array declaration
My 2c - Alternative type parameters syntax (ab)using @$:
On Wed, Jul 15, 2020 at 11:27 AM Randall O'Reilly
wrote:
> wouldn't gofmt remove the superfluous (z) in this case (and even with a
> more complex expression inside the parens, as the > operator would have
> appropriate precedence?), in existing code? And thus, would it not be
> reasonable to
Sorry to perseverate and belabor the point, but here's an analogy that makes
the point perhaps more strongly and succinctly:
Imagine that, for some reason, Go didn't have the array/slice element operator
syntax, [ ], and it was now going to be introduced in Go2, but instead of using
this
On Wed, Jul 15, 2020 at 10:47 AM Nick Craig-Wood
wrote:
> In my mind the use of [ ] clashes horribly with the array declaration
> syntax. When I see [int] in particular my brain says, ah array declaration
> of size int, what, no wait...
>
> This makes [identifier] mean two different things
On Wed, Jul 15, 2020 at 8:25 AM Michael Jones
wrote:
> nice. "gen" here is akin to the existing forward declaration of recursive
> inner functions. it says, "you are about to see something special and you
> need to know *this* about it."
>
>
The real name is "forall", and it presents a binding
As I wrote, parentheses are not needed for the common case of single type
parameter. If you have more than one, you need parentheses but note that this
is a *prefix* and any parsing ambiguities can removed by using a - if needed.
For your example it will be something like
(float64,int)PowN(1.2,
On Tue, 2020-07-14 at 23:53 -0700, Randall O'Reilly wrote:
> So, essentially, this puts the onus back on the parser programmers to
> definitively *rule out* the use of < > -- is it really that difficult
> / costly to do a bit of look-ahead and disambiguate the different use
> cases?
The absence
On Tue, 2020-07-14 at 23:05 -0700, Bakul Shah wrote:
> I don't much like square brackets or angle brackets or guillemets.
> But here is a different way
> of reducing the need for parentheses at least for the common case:
>
> A proposal for fewer irritating parentheses!
>
> One thing to note
Tagging onto this point: while Go deviates from other languages in a number of
important ways, syntax at the level of things like parens, brackets, etc is not
one of these key differences. It is almost entirely consistent with the "de
facto" C-style choices in this respect (to the extent that
nice. "gen" here is akin to the existing forward declaration of recursive
inner functions. it says, "you are about to see something special and you
need to know *this* about it."
On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah wrote:
> I don't much like square brackets or angle brackets or
I vote for <: and :>
type more on traditional keyboard is acceptable for me, since I don't use
generics much.
too much parentheses ( and ) in declaration is really hard to read,
confused my mind.
square brackets [ and ] should reserve for array and slice.
and, look ahead, we are able to
I don't much like square brackets or angle brackets or guillemets. But here is
a different way
of reducing the need for parentheses at least for the common case:
A proposal for fewer irritating parentheses!
One thing to note is that generic functions & types are *different* from
existing things
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 {*
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
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.)
>
>
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
86 matches
Mail list logo
