I'm certainly not privy to the nitty-gritty, but I'd encourage you to skim
over the Go Dev team meeting notes. It's really cool to see what people
have proposed over the years, how the team interacted with it, and
ultimately why yes, why no. It's been really educational.
The short of it is
I've hit this problems a few times, and I immediately thumbs-upped that
issue report.
To correct @Ben, I suggest the purest reasoning for an error being
displayed is "The process completed, and did not succeed". In your case,
@Ben, yeah, it was killed while waiting on something, but the normal
Noting that what @Brian%20Candler just said is bang on, I'll add that if
you use `math.Nextafter(y, math.Round(y))` or `y -
math.Nextafter(math.Mod(y, 0.01), math.Round(y))`, you can clean up a
poorly represented number. The following is Brian's example, but with those
two algorithms
@Paul%20Jolly, me likey! There's a really clean tokenizer implementation,
and if nothing else that's really nice baseline to mimic!
On Sunday, April 10, 2022 at 5:36:18 AM UTC-5 Andrew Pillar wrote:
> > I think there are two big advantages to making your application
> > consume either plain JSON
I skipped over to that package, and the doc says it converts from yaml to
json, and the marshals/unmarshals. I tried changing your snippet to use
struct tags with the key name as "json" instead of "yaml", and it
immediately behaved as expected: https://goplay.tools/snippet/PSZtr1YErD8
While
FWIW, I took a stab at a SIMD-oriented feature
(https://go.dev/issue/48499), but as @Ian%20Lance%20Taylor put it, it's
about the right approach. I skewed too far towards convenience in what I
proposed, gaining significant maintainability concerns.
On Thursday, April 7, 2022 at 3:35:35 PM UTC-5
Like, I get that the extra type-pointer for a declared struct of
float64+bool isn't that big of a deal, I do wish we could express tuple
types naturally. What you suggest is probably the closest we get for now.
For `if v, ok := value.(bool); ok && v`, the value is tuly 0. For `if v, ok
:=
I get what you're saying, and for what it's worth, you're absolutely
correct. Something like above is a set of tradeoffs, and I guess all I can
assert is that it works for me. I do think it's a good design, given Go's
lack of a None type to enforce well-defined behavior on a nil pointer
So, for what it's worth:
https://karthikkaranth.me/blog/functions-implementing-interfaces-in-go/
Otherwise, yeah. I'd love to be able to define interfaces with extra
methods for implementors, but if you arrange your code around "traits",
microstructs intended to present a possibly unergonomic
Uh, you should check the code:
github.com/jackc/pgtype/blob/master/float8.go If you know what you have and
what you're dealing with, and if you actually check the error result, you
do get safety. If you don't know what you've got, or if you're iterating
through the values, then you end up
:
> On Mon, Mar 28, 2022 at 12:39 AM Sam Hughes wrote:
>
>> @Axel, I really did mean what I said.
>>
>
> So did I.
>
> FTR, if OP would have asked for changes to the type-system to be able to
> represent non-nilable types, my response would have been different
ould want something like
> F(G(H(...)) to return to the call site of F with an erorr, without
> executing F or G in case H fails.
>
> On Apr 1, 2022, at 3:41 PM, Sam Hughes wrote:
>
> Point-free programming, or "tacit programming", is a convention that
> highlights
Yep. That’s the status quo. My tongue-in-cheek response to that as
objection is “If simply sufficient utility for a given task were valid as
objection to a new utility, why Go over C?” If you’re not posing that as
objection, no need to dwell on it.
Yeah. That’s exactly the kind of behavior I want
Point-free programming, or "tacit programming", is a convention that
highlights the intent without syntactic noise.
For those unfamiliar,
wikipedia: https://en.wikipedia.org/wiki/Tacit_programming
I want better function composition. "Write a helper function to route
values out to values in,
Thanks for clarifying that, @Brian. Yeah. It took a bit to warm up to that
approach, but the github.com/jackc/pgtypes convinced me that the results
were worth it. The benefits: A, package interpretation methods with a
piece of data, B, lazily valuate data when needed, and C, gain
fine to me - it is IMO
>>> fine for this code to cause a vet-failure:
>>>
>>> var x *int
>>> y := *x
>>>
>>> What I'm opposing is the original idea, for this code to cause a
>>> vet-failure:
>>>
>>> func (x *
My workaround like is something like `type String struct{string}.
It can be reasonably treated as a string for most cases in which as string
is needed, and it lets you convert back conveniently from any scope in
which it's reasonable for your program to know the difference.
On Friday, March
As written above, if that's the main thread, it is guaranteed to freeze in
a deadlock every time. I don't see a goroutine kicked off, so I'm assuming
you're trying to run that on the main thread, and you will be 100%, always,
forever stuck on the `case wch := <- ach {` line.
Channel reads are
Hey. I'm a rando internet jerk that just wrote you an issue!
I know I can't quite use your package, but I did point out an easy
improvement I think you could make, that'd make stacking iterators into
pipelines a little easier.
On Wednesday, March 23, 2022 at 5:14:10 AM UTC-5 Serge Hulne wrote:
Totally get where @Michael%20Troy is coming from. TypeScript is aware of
logical elements as part of ancestry for the current expression, and
provides some helpful warnings in cases where the expression can still be
visited with incompatible predicates.
@axel, it my feel counter-intuitive, but
Go is very intent on not implicitly casting types. This makes the
expression of a destructuring assignment difficult to imagine in Go. The
following represents a proposal to express both destructuring assignment
(x,y := ZtoXandY(Z)) and aggregating assignment (x := XfromYandZ(y, z)),
across
21 matches
Mail list logo
