FWIW, I’m not sure that I think it is the best outcome. If the expression is a
constant the loop can be omitted entirely - which I would hope the compiler
would do. And consequently the errors from the compiler should reflect that -
including the inverse if the expression is true.
> On Oct 11,
On Sat, Oct 12, 2024 at 5:35 AM Cleberson Pedreira Pauluci
wrote:
>
> I agree with @robert.
> The compiler cannot guarantee that the function will always return a value.
> Even though we can see that the loop will eventually return i value, the
> compiler isn't able to make this determination st
I have encountered the same discussion in the past at
https://groups.google.com/g/golang-nuts/c/jP_5kSTmSy4
Em sábado, 12 de outubro de 2024 às 00:35:08 UTC-3, Cleberson Pedreira
Pauluci escreveu:
> I agree with @robert.
> The compiler cannot guarantee that the function will always return a
>
I agree with @robert.
The compiler cannot guarantee that the function will always return a value.
Even though we can see that the loop will eventually *return i* value, the
compiler isn't able to make this determination statically.
Compile doesn't complain about the following code. I'm no expert
I agree with @robert.
The compiler cannot guarantee that the function will always return a value.
Even though we can see that the loop will eventually *return i* value, the
compiler isn't able to make this determination statically.
Compile doesn't complain about the following code. I'm no expert
On Fri, Oct 11, 2024 at 3:07 PM robert engels wrote:
>
> true is an expression, the compiler doesn’t inspect that it is a constant
> expression, thus you need the return statement
The exact rules can be seen at https://go.dev/ref/spec#Terminating_statements.
Ian
> > On Oct 11, 2024, at 4:57
true is an expression, the compiler doesn’t inspect that it is a constant
expression, thus you need the return statement
> On Oct 11, 2024, at 4:57 PM, Pierpaolo Bernardi wrote:
>
> Hello,
>
> the following code works as I expect: https://go.dev/play/p/pjKqpZyTU0d
>
> However, if I change lin
Hello,
the following code works as I expect: https://go.dev/play/p/pjKqpZyTU0d
However, if I change line 15 from
for i := 0; ; i++ {
to
for i := 0; true; i++ {
it does not compile. In my understanding the two should be equivalent,
but they are not. Maybe I'm missing a simple explanation?
--
Aren’t all of the maps/variables mapped and pinned in the kernel side anyway?
I think I would make this more portable and resilient using accessors and
maintain a reference to the memory and not expose the direct memory address.
The compiler should optimize/inline the atomic accesses anyway so t
On Fri, 11 Oct 2024 at 03:15, Robert Engels wrote:
>
> That’s what I was thinking. Thanks for providing the details. Rule of thumb -
> if you’re trying to do something and you’re the only one that’s trying it -
> you’re probably doing something wrong - or at least there is a much easier
> way.
10 matches
Mail list logo
