On Mon, Aug 18, 2025 at 9:49 PM Ruslan Semagin
wrote:
> In general, it seems to me that much of the opposition here comes from a
> general reluctance to introduce *any* new syntax into the language.
> If I try to summarize the proposal clearly, it is nothing more than
> syntactic sugar for a very
On Tue, 19 Aug 2025 at 06:49, Ruslan Semagin wrote:
> In general, it seems to me that much of the opposition here comes from a
> general reluctance to introduce *any* new syntax into the language.
>
I think that is a misreading of the responses. They where very specific to
your suggestion. I do
Axel, thanks for the answer.
I should clarify, I really expressed myself too generally, this is not true.
I just wanted to convey the main idea that the change does not complicate
the language that much, but this is of course a debatable issue.
In general, I think that the discussion is useful,
Bakul Shah,
Similarly, you can make a counter-argument that this is just specific
business logic and you can continue to use the usual loop.
вторник, 19 августа 2025 г. в 08:23:03 UTC+3, Ruslan Semagin:
> Axel, thanks for the answer.
>
> I should clarify, I really expressed myself too generall
> On Aug 18, 2025, at 9:41 PM, Ruslan Semagin wrote:
>
> Bakul Shah,
>
> >The other issue is information loss. If the channel is closed *while*
> >ch<-xs... is active, you don't know *how many* elements were passed.
>
> The reader has this information, and can also find out at any time how
Hi,
On Fri, 15 Aug 2025 at 13:10, Oliver Eikemeier
wrote:
> Static Analysis for Go Error Type Consistency: errortype Linter
>
> I've been investigating a class of subtle bugs in Go error handling
> related to pointer vs. value semantics with errors.As, and developed a
> static analysis tool to d
In general, it seems to me that much of the opposition here comes from a
general reluctance to introduce *any* new syntax into the language.
If I try to summarize the proposal clearly, it is nothing more than
syntactic sugar for a very specific case.
This syntactic sugar:
1. Does not compl
Bakul Shah,
>The other issue is information loss. If the channel is closed *while*
ch<-xs... is active, you don't know *how many* elements were passed.
The reader has this information, and can also find out at any time how many
elements are already in the channel.
вторник, 19 августа 2025 г.
Jason, thanks for the reply and advice, but I don't think I wrote anything
about the semantics of channels being ambiguous.
I think your reply is taking the discussion a bit off-track
вторник, 19 августа 2025 г. в 04:16:20 UTC+3, Jason E. Aten:
> Obviously channel semantics aren't ambiguous.
>
Obviously channel semantics aren't ambiguous.
Ruslan, channels do require perhaps an hour of careful study
and memorization to use effectively.
You cannot yolo-code or guess your way to working with channels. There
isn't anything to build intuition on--nothing prior to compare to.
You simply
The new go.dev website makes the language Spec hard to find, which is
unfortunate.
The spec is here -- it is one of the easiest language specs to read.
https://go.dev/ref/spec
The section on the built-in (pre-declared) error interface is here
https://go.dev/ref/spec#Errors
Although struct va
Regarding the "var _ error" bit - why not just look at the Error method to
see whether it is on a T or a *T? I haven't done a survey about it or
anything, but if I need to know whether to pass a T or a *T I often check
that type's methods.
On Friday, August 15, 2025 at 5:10:42 AM UTC-6 Oliver E
On Mon, Aug 18, 2025 at 9:25 AM 'andreas graeper' via golang-nuts
wrote:
>
> type I interface { m()bool }
> type T struct { x bool }
> func (o T) m()bool { return o.x }// o:object
> func (p *T) m()bool { return p.x } // p:pointer
>
> both does not work. it is not possible to implement I fo
type I interface { m()bool }
type T struct { x bool }
func (o T) m()bool { return o.x }// o:object
func (p *T) m()bool { return p.x } // p:pointer
both does not work. it is not possible to implement I for T and *T ( m
already defined )
func fi(i I){}
func fp(i*I){}
fi(o) if T implements
What part of the semantics of a channel are “ambiguous”?
From: 'Axel Wagner' via golang-nuts
Sent: Sunday, August 17, 2025 6:45 AM
To: Ruslan Semagin
Cc: golang-nuts
Subject: Re: [go-nuts] Slice expansion in channel send statements (ch <- X...)
This message was sent by an external party.
On
15 matches
Mail list logo
