> On Jul 18, 2020, at 9:00 PM, Ian Lance Taylor wrote:
>
> On Sat, Jul 18, 2020 at 3:43 PM wrote:
>>
>> This seems to work: https://go2goplay.golang.org/p/8veymwXYCoZ
>>
>> Still uses interfaces internally.
>
> Compare that to https://go2goplay.golang.org/p/8U4h9flkhFN.
>
> Ian
Seems lik
On Sat, Jul 18, 2020 at 4:55 AM Markus Heukelom
wrote:
>
> Concerning the current generics proposal, was it every considered to not
> allow type contracts at all?
>
> No type contracts would mean that generic functions can only use =, & on
> variables of parametric types, as these are always ava
On Sat, Jul 18, 2020 at 4:00 AM Markus Heukelom
wrote:
>
> Concerning only the current proposal, is there a reason why we shouldn't
> allow specifying the parametric types for a whole bunch of functions / types
> at once?
>
> Like:
>
> generic (type T) (
>
> func Average(value []T) {...}
> func
On Sat, Jul 18, 2020 at 12:19 AM Tyler Compton wrote:
>
> I'm beginning to think that community members (like myself) can't reasonably
> be expected to put in the necessary effort to champion a sizable language
> change. I think it was Ian who made multiple generics draft proposals just to
> re
On Sat, Jul 18, 2020 at 3:43 PM wrote:
>
> This seems to work: https://go2goplay.golang.org/p/8veymwXYCoZ
>
> Still uses interfaces internally.
Compare that to https://go2goplay.golang.org/p/8U4h9flkhFN.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-
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 readability
While I have over 50 years of programming experience, I am also quite old
and sometimes have senile moments.
I once wrote an extremely well-written bug report complaining about the use
of the backtick which is not on my keyboard, explained why it should not be
used, and then presented a workaro
пт, 17 июл. 2020 г. в 05:40, Justin Israel :
>
>
>
> On Friday, July 17, 2020 at 11:21:32 AM UTC+12 va...@selfip.ru wrote:
>>
>> вт, 14 июл. 2020 г. в 18:39, Jake Montgomery :
>> >
>> > I agree, it seems like an unfortunate oversight. You can do it without the
>> > slice tricks: https://play.golan
This seems to work: https://go2goplay.golang.org/p/8veymwXYCoZ
Still uses interfaces internally.
--
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 email
to golang-nuts+unsu
> On Jul 16, 2020, at 3:35 PM, Ian Lance Taylor wrote:
>
> The language is stable and is not looking to change in any
> significant way (except perhaps for adding generics). We've realized
> that we need to be upfront about that.
The Go2 process certainly created the expectation that the la
I don't think there's any real risk of guillemets ever being adopted. But since
this appears to be a serious proposal...
Even as a European programmer using a custom keyboard with programmable
firmware and layout (so essentially the optimal target audience for the
proposal) it seems cruel and u
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?
It is a serious suggestion. Our editors are flexible enough to allow us to use
control keys to generate these characters. Our ethnocentric, ASCII limited view
of programming languages would benefit from more flexibility when it increases
readability.
Jon
Jon Conradt
——
j...@theconradts.com
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 re
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 language
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
You are asking about the size of the archived go distributions, NOT about
the size of programs built with go, correct?
On Friday, July 17, 2020 at 5:33:31 PM UTC-4, yangw...@gmail.com wrote:
>
> This issue is only the binary file, I said is go archive size .
> Such as go1.14.6.darwin-amd64.tar.gz
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
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 a
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 a
On Sat, Jul 18, 2020 at 1:55 PM Markus Heukelom
wrote:
> Concerning the current generics proposal, was it every considered to not
> allow type contracts at all?
>
> No type contracts would mean that generic functions can only use =, & on
> variables of parametric types, as these are always availa
Concerning the current generics proposal, was it every considered to not
allow type contracts at all?
No type contracts would mean that generic functions can only use =, & on
variables of parametric types, as these are always available for all types.
Nothings else is allowed.
This would remo
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
Thanks for the answer.
Concerning only the current proposal, is there a reason why we shouldn't
allow specifying the parametric types for a whole bunch of functions /
types at once?
Like:
generic (type T) (
func Average(value []T) {...}
func Median(value []T) {...}
// etc
)
generic (type T1, T
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 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
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
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
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
There seems to be an assumption that, given enough time and effort, any
idea could get accepted into the language. But that clearly can't be so. It
might be frustrating to hear that your particular idea just isn't
considered a good idea, but it's a necessity that most ideas go that route.
It's not
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
I have a proposal for improving Go proposal procedure.
It stems from two "issues" highlighted in several occasions:
1. core Go team is spending an increasing amount of time discussing a
larger number of proposals.
All of them are commented and discussed by core Go team, and in the end
I'm beginning to think that community members (like myself) can't
reasonably be expected to put in the necessary effort to champion a sizable
language change. I think it was Ian who made multiple generics draft
proposals just to reject them himself, then Ian and Robert Griesemer spent
more untold h
34 matches
Mail list logo
