dbaupp

36 ms·

391.
by dbaupp 9y ago
It doesn't require that. Flow seems to accept all sorts of variations on the following (including X | X): type X = { foo: string } type Y = { foo: string, bar: string } type Foo = X | Y (Y is a subset of X in that case.)
392.
by dbaupp 9y ago
OSM is essentially a database of points and lines, each with a (loosely defined) soup of tags attached to it. Highly flexible (annoyingly so, if you've got a single focus area) and not in a "layer" format.
393.
by dbaupp 9y ago
The former is a (small) generalization of the latter, tacking on a tag to forcibly ensure the sets are disjoint. It's not worth thinking of them as different. In any case, Flow doesn't require that the sides of the | are different
394.
by dbaupp 9y ago
> some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has a different type, even if they resolve to the same types upon evaluation of the future - basically abusing
395.
by dbaupp 9y ago
Async/await can be cheaper given other constraints, e.g. Go ends up using a lot of GC infrastructure to keep stacks small/minimize memory use, which makes FFI to C-style languages expensive. If syntax is all that matters, then seq
396.
by dbaupp 9y ago
Swift enums are sum types. Various languages use different keywords to access the same concept: - Rust: 'enum' - Swift: 'enum' - Haskell: 'data' - F#: 'type' - Ocaml: 'type' > Also I thi
397.
by dbaupp 9y ago
Disjoint union in mathematics is exactly the universal construction you're calling sum types: https://en.wikipedia.org/wiki/Disjoint_union (The Flow use of the name doesn't seem to quite match the mathemati
398.
by dbaupp 9y ago
> Just in case it's not clear, the disjoint union of sets "merges" elements that are identical whereas in the (direct) sum each element gets tagged with where it comes from. That's just a union. The disjoint union (
399.
The Exclusive Top Floor algorithm: Super-fast univariate distributions sampling(sbarral.github.io)
3 points by dbaupp 9y ago|0 comments
400.
by dbaupp 9y ago
> It's not like nobody "realized" we needed to expose vendor intrinsics before then, but it just hadn't been worked on. It had been... in 2015. :)
401.
by dbaupp 9y ago
> 3. When developing SIMD related libraries which need to be portable across multiple CPU versions you may set up a CPUID mask (so trap, then hide features) to ensure compatibility on legacy computers. Huh? My impression was CPUID was
402.
by dbaupp 9y ago
> I'm sorry if it seems like I'm being pedantic about this point but it's a huge issue of contention for those of us who used C++ to squeeze every ounce of performance out of a platform. You're being pedantic about
403.
by dbaupp 9y ago
I think you're still looking at too much of the picture: this discussion is specifically about error handling in destructors (and how this affects finally/scope(exit)). There's numerous reasons why the checked, explicit, firs
404.
by dbaupp 9y ago
You're jumping around: exceptions being checked or not is orthogonal to returning errors from a destructor. It's true that being unchecked may make it harder to know when you need to, but the point stands that the ability to retur
405.
by dbaupp 9y ago
"Just" passing a reference elides how clunky and annoying it is: depending on the code, it requires extra nested scopes, along with remembering to actually handle the error. Even the case of propagating the error upwards requires
406.
by dbaupp 9y ago
To be fair, Rust doesn't solve the errors-in-destructors thing any better: Drop::drop can't return anything.
407.
by dbaupp 9y ago
If you're wearing x-ray glasses to look at the implementation details, no language is safe (e.g. CPython's vectors/lists are written in C). It isn't a useful contention.
408.
by dbaupp 9y ago
In this case, safer == memory safety (which is not a Rust-specific thing), not general forms of correctness, and the comparison in the original comment is to C and C++, not statically typed languages with a GC.
409.
by dbaupp 9y ago
The trace_macros! stringifier isn't inserting parens when required: due to the use of 'expr' the macro is treating 3 + 7 as a single node X , and then the multiplication with 4 is, in the AST, X * 4 (i.e. correct). The thi
410.
by dbaupp 9y ago
While the approach you suggest usually works well, it doesn't in this case: FILE_NAME_INFO[1] uses a "flexible array member"[2] (although not the C99 version of it), of requiring a dynamically sized character array in the str
411.
by dbaupp 9y ago
> And what are those safety guarantees? This is the part where I see a lot of handwaving. I think this is the contention: correct me if I'm wrong, but you're saying, that, in practice, the safety guarantees of Rust are curren
412.
by dbaupp 9y ago
I'm still not understanding: other than the hardware/global state thing in another comment in this thread[1], what's a program that demonstrates this "composing safe interfaces is unsafe" property? The example in th
413.
by dbaupp 9y ago
Thanks! I'm not convinced that the statement in the paper translates into what you said: the key piece of that paragraph is "or seems to be". The Leakpocalypse problem was one piece of code (crossbeam's scoped threads AP
414.
by dbaupp 9y ago
The example is illustrative enough: all the array needs to be misaligned in practice is a small value on the stack near it, e.g. if the Rust code has `let x: u8 = 1;` inserted after the array (or, I imagine, `uint8_t x = 1;` in the C, etc.)
415.
by dbaupp 9y ago
> One known trap is that it is not sufficient to demonstrate that Rust code without "unsafe" blocks cannot observe unsafe behavior in your library. I'm curious: what does this mean/could you point me to the part of
416.
by dbaupp 9y ago
The ability to state that a type only conforms to a protocol if its generic parameters satisfy certain bounds. https://swift.org/blog/conditional-conformance/
417.
by dbaupp 9y ago
An `unsafe` block only enables extra features, it doesn't change existing behaviour of safe Rust. Specifically, it allows calling `unsafe` functions (FFI and pure Rust `unsafe` ones), dereferencing raw pointers and some minor other stu
418.
by dbaupp 9y ago
> Rust's system for external C calls should be more like that and less about casts to raw pointers. It seems a rosy-eyed view to think that this would helping safety significantly, and would require a lot of effort: it's likely
419.
by dbaupp 9y ago
Rust's error messages are (well, try to be) similar, and in fact explicitly inspired by Elm: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com...
420.
by dbaupp 9y ago
Rust has a strong policy of adding tests when adding/changing code, so almost all error messages are tested in some form, including "UI" tests, that check the exact formatting. Additionally, there's https://do

More ›