FWIW (which may not be much) I've settled on explicitly naming my return
values in the function declaration. If the function returns include an
error, I name always name it err. The general pattern is
func foo() (v someType, err error) {
err = doSomething()
if err != nil {
err =
On Fri, Nov 12, 2021 at 10:49 PM Ian Lance Taylor wrote:
> On Fri, Nov 12, 2021 at 9:23 AM 'Axel Wagner' via golang-nuts
> wrote:
> >
> > On Fri, Nov 12, 2021 at 6:20 PM tapi...@gmail.com
> wrote:
> >>
> >> How much complicated? Is it similar to
> >>
> >> func foo(int int) {}
> >
> >
> >
On Thu, Nov 11, 2021 at 5:57 PM Shanshan He wrote:
>
> The two instructions are :
> MOVD$"".bar.func1·f(SB), R0
> and
> MOVD$"".bar.func1(SB), R0
They refer to different symbols. The middle-dot in the first
instruction is just part of the symbol name.
Ian
--
You received this message
On Fri, Nov 12, 2021 at 9:20 AM Shreyas Sreenivas
wrote:
>
> Note, I've already looked at https://golang.org/issue/28987,
> https://golang.org/issue/19814, and https://golang.org/issue/28438. All of
> them require them to make a change that breaks the compatibility promise. I
> want to explore
On Fri, Nov 12, 2021 at 9:23 AM 'Axel Wagner' via golang-nuts
wrote:
>
> On Fri, Nov 12, 2021 at 6:20 PM tapi...@gmail.com wrote:
>>
>> How much complicated? Is it similar to
>>
>> func foo(int int) {}
>
>
> No. As I said, the situation is different, as type-parameters must be able to
> be
Your function is declared to return only a single string, and the "return"
statement returns immediately from the function with that single string, so
this is what you've coded it to do.
If you want to return multiple values, then (1) you'll have to declare the
function to return a slice of
You're returning right after ranging through the first value, thus
ending/exiting the function.
Try: https://play.golang.org/p/0n1g8HXxobI
On Friday, November 12, 2021 at 10:20:10 AM UTC-7 bishwajits...@gmail.com
wrote:
> HI, need help in understanding what i am making mistake of not able to
OK, I will try it several days later.
On Saturday, November 13, 2021 at 1:21:08 AM UTC+8
axel.wa...@googlemail.com wrote:
> Yes, the doc is outdated. Since then, several changes have been made to
> the design, to accomodate issues that either came up during the discussion
> or where
To be clear: You sent a follow-up E-Mail to your original code, to replace
`int` with `[]byte`. That substitution is, of course, necessary to make the
code compile. So, specifically, this compiles fine:
package main
import (
"fmt"
)
type byteview interface{string | []byte}
type ByteView[T
On Fri, Nov 12, 2021 at 6:20 PM tapi...@gmail.com
wrote:
> How much complicated? Is it similar to
>
> func foo(int int) {}
>
No. As I said, the situation is different, as type-parameters must be able
to be self- and mutually referential.
>
>
>>
>>
>>>
>>>
or basically any
Why not? The comment "[]byte does not satisfy comparable" seems irrelevant,
as you don't use that constraint anywhere. It seems pretty well-defined, if
strange and pointless, code.
On Fri, Nov 12, 2021 at 6:20 PM tapi...@gmail.com
wrote:
> fine? It should not.
>
> On Friday, November 12, 2021
Yes, the doc is outdated. Since then, several changes have been made to the
design, to accomodate issues that either came up during the discussion or
where discovered after - one of the more significant is
https://github.com/golang/go/issues/45346, but there are others.
That's why I said we should
Note, I've already looked at https://golang.org/issue/28987,
https://golang.org/issue/19814, and https://golang.org/issue/28438. All of
them require them to make a change that breaks the compatibility promise. I
want to explore another way of defining enums that is backward compatible.
*Enums
On Friday, November 12, 2021 at 6:07:11 PM UTC+8 axel.wa...@googlemail.com
wrote:
> And FWIW, just to illustrate the expected complexity: We also want these
> two declarations to mean the same:
> func A[T A]()
> func B[T interface{ A }]()
> So the rules also need to accommodate that. It gets
Are the followings also intended?
func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
return T // T (type) is not an expression
}
func Bar[T any](x T) T {
var T = x // T redeclared in this block
return T
}
On Friday, November 12, 2021 at 6:07:11 PM UTC+8
HI, need help in understanding what i am making mistake of not able to
return all the values. Below is the sample code from Playground.
https://play.golang.org/p/EMN830T0Lvr
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from
On Friday, November 12, 2021 at 6:04:01 PM UTC+8 axel.wa...@googlemail.com
wrote:
> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
> wrote:
>
>>
>>
>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8
>> axel.wa...@googlemail.com wrote:
>>
>>> I suspect this issue is hard/impossible to
fine? It should not.
On Friday, November 12, 2021 at 3:04:20 PM UTC+8 axel.wa...@googlemail.com
wrote:
> Please ask an actual question, don't just post some code.
> FTR the code you posted (with the substitution you suggest) compiles and
> runs fine using gotip.
>
> On Fri, Nov 12, 2021 at
Nice, make it simple.
On Friday, November 12, 2021 at 3:08:31 PM UTC+8 axel.wa...@googlemail.com
wrote:
> I don't prefer either. I decide on a case-by-case basis. I generally
> ignore the question of scope, though. The relevant question (to me) is
> readability. If the statement is short, I
The SliceConstraint example also doesn't work.
Is the doc I mentioned outdated?
On Saturday, November 13, 2021 at 1:13:13 AM UTC+8 tapi...@gmail.com wrote:
> And this fails to compile, although the docs says it is valid:
>
> // sliceOrMap is a type constraint for a slice or a map.
>
And this fails to compile, although the docs says it is valid:
// sliceOrMap is a type constraint for a slice or a map.
type sliceOrMap interface {
[]int | map[int]int
}
// Entry returns the i'th entry in a slice or the value of a map
// at key i. This is valid as the
The proposal design docs
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md)
mentions:
// structField is a type constraint whose type set consists of some
// struct types that all have a field named x.
type structField interface {
I think all of this will probably be handled with wrapper collections types and
the iterator pattern.
Generics should make this easy. It would be great is range supported this but
it seems doubtful.
> On Nov 12, 2021, at 10:37 AM, 'Axel Wagner' via golang-nuts
> wrote:
>
>
> It is still
It is still a different operation. For example, a range over a map is not
necessarily deterministic.
If you continue to ask detail-questions like this, it would be useful if
you could provide an actual program you'd want to write using them.
Otherwise, it makes a lot more sense to just wait for
On Fri, Nov 12, 2021 at 7:48 AM Miguel Angel Rivera Notararigo <
ntr...@gmail.com> wrote:
> I tend to use errX (X is adapted according to context) for function scoped
> errors, and err for block scoped errors
>
> func MyFunc() error {
>> v, errDS := doSomething()
>> ...
>> errDA :=
On Fri, Nov 12, 2021 at 11:54 PM Axel Wagner
wrote:
> Oh, sorry, I just re-read. Your example still requires `range` to return
> distinct types, so that probably shouldn't work.
>
Not this reason:
func Bar[T []byte|map[int]byte](s T) {
for i, v := range s { _, _ = i, v} // cannot range
Oh, sorry, I just re-read. Your example still requires `range` to return
distinct types, so that probably shouldn't work.
On Fri, Nov 12, 2021 at 4:52 PM Axel Wagner
wrote:
> The error message gives you a reason - there is no single underlying type.
> This works:
>
> type B []byte
> func Bar[T
The error message gives you a reason - there is no single underlying type.
This works:
type B []byte
func Bar[T []byte|B](s T) {
for range s {}
}
But yes, your example arguably should be made to work eventually. I would
suggest filing an issue about that.
On Fri, Nov 12, 2021 at 4:47 PM
This one doesn't compile either.
So the range operation doesn't support values of parameter types?
type MyByte byte
func Bar[T []byte|[]MyByte](s T) {
for range s {} // cannot range over s (variable of type T constrained
by []byte|[]MyByte) (type set has no single underlying
}
On Friday,
On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com
wrote:
> On Friday, November 12, 2021 at 11:10:17 PM UTC+8
> axel.wa...@googlemail.com wrote:
>
>> `range s` works differently for string and []byte. In the former case it
>> iterates over utf8-encoded unicode codepoints, in the latter it
On Friday, November 12, 2021 at 11:10:17 PM UTC+8 axel.wa...@googlemail.com
wrote:
> `range s` works differently for string and []byte. In the former case it
> iterates over utf8-encoded unicode codepoints, in the latter it iterates
> over bytes.
>
It is true, but why it matters here?
>
It's hard to say exactly, at this point, because the spec-changes for
generics are not yet written.
I don't think the behavior you observe is bad, but we'll have to see how we
can put it into the spec.
Currently, function parameters are scoped to the function body. Uniqueness
is litigated via a
`range s` works differently for string and []byte. In the former case it
iterates over utf8-encoded unicode codepoints, in the latter it iterates
over bytes.
On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com
wrote:
>
> func Bar[T []byte|string](s T) bool {
> for _, v := range s { // cannot
func Bar[T []byte|string](s T) bool {
for _, v := range s { // cannot range over s (variable of type T
constrained by []byte|string) (T has no structural type)
if v > 100 {
return true
}
}
return false
}
The message is quite confusing.
--
You received
This one compiles okay:
func Bar2[T any](x T) T {
{
var T = x // T redeclared in this block
return T
}
}
So the parameter type is declared at the local top block?
On Fri, Nov 12, 2021 at 9:43 PM T L wrote:
> It is strange that my recent comments are deleted automatically if
It is strange that my recent comments are deleted automatically if they are
posted from the web interface.
But now from the email interface.
On Fri, Nov 12, 2021 at 9:40 PM T L wrote:
> Are the followings also intended?
>
> func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
>
Are the followings also intended?
func Foo[T any](T T) T { // (the 2nd) T redeclared in this block
return T // T (type) is not an expression
}
func Bar[T any](x T) T {
var T = x // T redeclared in this block
return T
}
On Fri, Nov 12, 2021 at 6:03 PM Axel Wagner
wrote:
>
>
> On Fri,
I tend to use errX (X is adapted according to context) for function scoped
errors, and err for block scoped errors
func MyFunc() error {
> v, errDS := doSomething()
> ...
> errDA := doAnotherthing()
> }
>
if err := doAnotherthing(); err != nil {
> return err
> }
>
That way you don't
And FWIW, just to illustrate the expected complexity: We also want these
two declarations to mean the same:
func A[T A]()
func B[T interface{ A }]()
So the rules also need to accommodate that. It gets only more complicated
from there.
On Fri, Nov 12, 2021 at 11:03 AM Axel Wagner
wrote:
>
>
> On
On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com
wrote:
>
>
> On Friday, November 12, 2021 at 5:33:19 PM UTC+8 axel.wa...@googlemail.com
> wrote:
>
>> I suspect this issue is hard/impossible to avoid, because it must be
>> possible to self- and mutually reference type-parameters, in a way that
On Friday, November 12, 2021 at 5:33:19 PM UTC+8 axel.wa...@googlemail.com
wrote:
> I suspect this issue is hard/impossible to avoid, because it must be
> possible to self- and mutually reference type-parameters, in a way that
> it's not for normal parameters, to allow to write something
I suspect this issue is hard/impossible to avoid, because it must be
possible to self- and mutually reference type-parameters, in a way that
it's not for normal parameters, to allow to write something like
type Equaler[T any] interface {
Equal(T) bool
}
func Eq[T Equaler[T]](a, b T) bool {
`I do find this rather annoying, to the point where I'll stick a "var err
error" at the top of a function rather than have the first assignment be
different to the subsequent ones. `
I think this is a good way. I usually code in this way if there're multiple
error assignments.
If each error
Oh, I have a typo error, in the second pattern, `err := doAnotherthing()`
should be `err = doAnotherthing()`.
On Friday, November 12, 2021 at 4:02:34 PM UTC+8 Brian Candler wrote:
> func MyFunc() error {
> v, err := doSomething()
> ...
> err := doAnotherthing()
> }
>
> That won't compile
I expect the following code compilers okay, but it doesn't.
It looks All the three "I" in the Bar function declaration are
viewed as the type parameter, whereas the second one is
expected as the constraint I (at least by me).
package main
type I interface { M() }
func Foo(i I) {
i.M()
}
func
func MyFunc() error {
v, err := doSomething()
...
err := doAnotherthing()
}
That won't compile anyway; the second assignment would have to be
err = doAnotherthing()
See: https://play.golang.org/p/pvNC7YHI88j
I do find this rather annoying, to the point where I'll stick a "var err
46 matches
Mail list logo
