"or main could be lazy and let `error<-` panic when err != nil:"
* would require that `action`'s signature be `func action() (string,
error<-)`
On Monday, January 9, 2023 at 12:10:25 PM UTC-8 Oliver Smith wrote:
> A complete example (followed by the code it replaced)
if err != nil {
return err
}
fmt.Println(motd, pwd)
return nil
}
func main() {
if err := action(); err != nil {
fmt.Printf("ERROR: %s\n", err)
}
}
```
https://play.golang.com/p/2_pk-FNv-dk
On Tuesday, December 27, 2022 at 3:52:41 PM UTC-8 Oliver Smith wrot
Discussing implementations of the (returns..., error) idiom from golang in
other languages, I noted a common thing: non-go developers often
conceptualized this as a back channel and didn't intuit that it's just a
return-value convention.
This lead me to a new idea for addressing the excess verb
What's the Big-O on determining whether N functions are
a/ identical,
b/ similar but expressing potentially unique behavior,
c/ subtly varied.
identical, assuming x and y have the same type:
func (t *T) fX() bool {
return t.x == t.z
}
func (t *T) fY() bool {
return t.y ==
Recognizing this is likely to be a dead horse already flogged to infinity,
I've been unsuccessful trying to find discussions on the topic of why while
was nixed in-favor of the more verbose and error-prone for-based
implementations, hoped someone could furnish links?
c.f
// concise, non-repeti
Do I understand correctly that "last return value is error" is purely
convention and there is no formal error handling in current go?
My instinct is to leverage the 'else' keyword along with the notion of a
"stock error whose return list's last element is type error with value !=
nil.
func n
Looking at how go compiles/optimizes a couple of common constructs, which I
boiled down to a simple '\t' replacement loop.
godbolt of sources: https://go.godbolt.org/z/Pnf3vh
```
func v1(s []byte, detab bool) (d []byte) {
d = make([]byte, len(s))
for i := 0; i < len(s); i++ {
char := s[i
n indicator the caller retains responsibility for
closing the channel.
On Sunday, October 25, 2020 at 5:18:27 PM UTC-7 axel.wa...@googlemail.com
wrote:
> On Mon, Oct 26, 2020 at 12:29 AM Oliver Smith <
> oliver...@superevilmegacorp.com> wrote:
>
>> This pattern/idiom is ve
Looking at how C++ has chosen to provide it's users with generators served
as a bit of a wake-up call for me on how we implement them in Go. We write
them backwards:
```go
func getPositiveOdds(numbers []int) <-chan int {
channel := make(chan int)
go func () {
defer close(channel)
Do godbolt links get eaten? https://godbolt.org/z/vbeobs
On Tuesday, September 1, 2020 at 12:53:57 PM UTC-7 Oliver Smith wrote:
> In the process of developing a piece of middleware, I need to translate
> from a bit-array into a bitmask. I am struggling to find a way to express
> t
In the process of developing a piece of middleware, I need to translate
from a bit-array into a bitmask. I am struggling to find a way to express
this in go that doesn't result in terrible performance.
The approaches I would try in most other languages were along the lines of:
```
mask = (bool1
I recognize the hefty constraints in introducing generics, but for me the
most egregious part is the cognitive and visual overhead it introduces by
pushing more and more stuff off-screen-right and the processing overhead of
so many sequences of parens on the same line.
My key thought is "the sa
12 matches
Mail list logo
