Hmm... It appears that there were] (⚙ D119284 [IR] Add intrinsics to represent complex multiply and divide instructions.) [some plans for complex numbers, but they are not entirely supported for now. It's odd because I thought there were some plans for doing so. I don't think this is a problem, as we can now use a platform dependent representation as a struct for the complex types. The advantage is still C FFI.

tczajka: > Here there is no better alternative in typical use. Be kind of nice if we added some then. To be very very clear: _I don't think just adding a warning is a complete solution_... and it's a bit of a straw man to respond to that position.

In several programs, I've taken to writing safety comments on my uses of arithmetic operators. Arithmetic is pretty much the most dangerous thing you can do in safe Rust (EDIT: not counting I/O or other similar interactions with the environment outside the program) – you need a lot of reasoning about the program to know that it isn't going to give you a panic or the wrong result. (Note that wrapping is actually often a worse outcome than panicking, because the program will continue running but using the wrong numbers.)

Well rust doesn't use MLIR, so that's not particularly relevant? (MLIR has all kinds of dialects, like sparse tensors for example.) Whereas if there was, say, a `llvm.complex.mul.f32` intrinsic that handled complex multiplication properly for us, that would be a stronger reason to have it built-in in some way, as it would be something a crate wouldn't use. (Like how https://doc.rust-lang.org/std/primitive.u128.html#method.carrying_mul_add is implemented on LLVM in a way not possible in a crate, which is one reason it's nice to have as a `core` method.)

idanarye: > This whole "sorted happy path" for binary tree insertions sounds weird to me But BTree is _not_ a binary tree. It's a b-tree with a much higher branching factor. Binary search trees are definitely not a very good idea on today's machines that love sequential memory access and hate indirection and branches. And unpredictable branches even more.

This does seem like a personal preference, that's why I suggested to reuse macro syntax (with an exclamation mark) to also distinguish between macros and attributes.

pitaj: > What if we just gave a sorted happy path to `extend`? Have it track the maximum item so it can skip the traversal in that case. This whole "sorted happy path" for binary tree insertions sounds weird to me. The tree still has depth - you still need to traverse it and rebalance it on every insertion, and for that it doesn't really matter if the items are sorted or not - it's still `O(log n)` per insertion. I'd understand if `bulk_build_from_sorted_iter` was accepting an `ExactSizeIterator` (and then it could easily deduce the entire structure of the tree) but it doesn't - so I although I did not look into how it works, I doubt its optimizations are as good as what `map_values` can achieve. The biggest advantage of `map_values` is that it can just copy the structure of the original tree over to the new one. This means that it doesn't need to navigate the tree from the root on each insertion, and doesn't need to rebalance it - it'll be unbalanced during its construction and only be fully balanced at the very end. This, BTW, mean it's worthwhile to also make `&` (and `&mut`) versions of these methods (`where K: Clone`, of course)

I agree. I'll add it as a major factor in the ACP and will change it as soon as I can.

MLIR does

For the purposes of making the simplest possible ACP, please leave out the bits involving new custom lang syntax, and assume that this will have a constructor like `c32::new(2.0, 4.0)`.

SciMind2460: > LLVM has a intrinsic for this, but it is not used in Rust as yet. Can you link where that is in the langref? None of the places it says "complex" (that I found) are about complex _numbers_.

I'm not sure LLVM _does_ implement numerically safe complex multiply, at least not in all cases.[1] Still, "this is the compiler's job" is a good answer to the question I asked, and "the compiler has intrinsics for complex arithmetic that (in principle) handle all the floating-point corner cases and are legible to optimization, but Rust doesn't expose them" is IMO a stronger argument for including complex numbers in the stdlib than just "there are a lot of crates already that define complex types and they're not interoperable". (You do mention that LLVM has these intrinsics in your problem statement, but you don't, IMO, give that the importance it deserves.) * * * 1. for example, llvm-project/compiler-rt/lib/builtins/muldc3.c at 5017370a1ce5009aed2855b645194bc141f72a2d · llvm/llvm-project · GitHub handles the naive formula producing a NaN that ought to be Inf, but it doesn't look like it even tries to detect the situation where the difference of two infinite-precision intermediates would be in the _finite_ representable range of IEEE double. ↩︎

dlight: > I think many APIs panic because unwrapping is too verbose. Sure, but my point is that when we do decide to have a panicking API, there is no tradition or need to call it `X_or_panic`. For example, `slice::swap` is not called `slice::swap_or_panic`. I don't really see how `unwrap` is any different. If you `unwrap` an externally-provided `Option`, that's bad engineering, but the same applies to `slice::swap`: if you `swap` using a user-provided index without checking it's valid, that's bad engineering. This is just a general principle that you should not trust external user inputs. But I don't think a good solution is to warn or make long scary names for functions that may panic.

ryanavella: > I would like to use `.unwrap()` as a terser `unreachable!()`, but I work with developers whose usage of it suggests they think it is more like `panic!()`. You could argue this was one domino in the Cloudflare chain-of-dominos: a team environment where each developer had different ideas of what `unwrap` means. I feel exactly this way, there's many meanings for `.unwrap()` and each person has their own favorite meaning. Here is another data point: the lang team feels like `.unwrap()` exists largely for quick and dirty code, that is, code that disregards failure modes to simplify development. Which I think differs from the point of view that `.unwrap()` is a sugar for `unreachable!()`, and thus has a place even in code that thoroughly checks and recovers from errors: it's to be used when there is absolutely no way an error could happen, but the type checker isn't smart enough to figure it out. tczajka: > Plenty of functions will panic when their preconditions are not satisfied. It's part of the regular function contract that a function will panic when you give it invalid inputs. So I don't think adding `_or_panic` or `_or_unreachable` here helps. I think many APIs panic because unwrapping is too verbose. I mean, panicking because the input is invalid due to programming error is ok and expected. But if the input comes from the user, it's probably better to not panic but return `Result`, because I want to display this error to the user and ask him to try again. (or else, to prevent a panic you need to validate an input before passing it to the function that will validate it _again_ - a situation that generally is solved by the "parse, don't validate" pattern) But APIs generally don't know where their inputs come from. so it's somewhat common for a Rust API to not decide what's more appropriate, returning `Result`/`Option` or panicking, and thus provide both variants. Which would be probably redundant - if you want to panic, why not call the non-panicking variant and unwrap it? Except that the verbosity of sprinkling `.unwrap()` makes the code harder to read, so people prefer calling a panicking API.

RelunSec: > This will be very useful in some situations. Standard response: you're discussing a feature without elaborating on the motivation. The motivation is more important than any specific feature. What are you trying to do? Avoid name conflicts? Define your crate's API? ...

toc: > I'd suggest you use `#![allow(those_unwraps)]`. Wouldn't this be unprecedented? A warn-by-default lint typically exists because there is a better alternative almost every time, not because some people may use the function incorrectly. Here there is no better alternative in typical use. Wouldn't it be the first warning where the default suggestion is "just switch off the warning"? richard-hajek: > introducing `unwrap_or_panic()` and `unwrap_or_unreachable()` would be good for the stdlib Plenty of functions will panic when their preconditions are not satisfied. It's part of the regular function contract that a function will panic when you give it invalid inputs. So I don't think adding `_or_panic` or `_or_unreachable` here helps. If you think "unwrap" is the right verb to use, `.unwrap()` is a good function name.

or instead to make it more safer more safer pub use crate::mymod::pub *; Or similar that export everything in to the crate root that is public.

A comment from irc: > 15:31 <saati> kpcyrd: with the try version the original collection gets dropped on an error? Most of the time I'd probably be fine with dropping both collections in case of an error, this would be analogous to: impl<A, E, V> FromIterator<Result<A, E>> for Result<V, E> where V: FromIterator<A>, Alternatively `BTreeMap::try_map_values` could return a `Result<BTreeMap<A, C>, (E, BTreeMap<A, B>, BTreeMap<A, C>)>` (error, old collection, new collection - the type complexity is slightly unfortunate though, and the value that was causing the error would be missing/lost). Having an optimized `.extend()` would also work for my use-case.

pitaj: > How do you ensure that the mapped value has the same order as the original value? `BTreeMap` is sorted by key, so if you're only mapping values the order doesn't change. pitaj: > What if we just gave a sorted happy path to `extend`? Have it track the maximum item so it can skip the traversal in that case. That seems like a great potential optimization.

How do you ensure that the mapped value has the same order as the original value? What if we just gave a sorted happy path to `extend`? Have it track the maximum item so it can skip the traversal in that case.

This doesn't add a new primitive, unless you're talking about the syntax. But that can always be added later.

tczajka: > I only use `unwrap` for the `unreachable!` case. For `todo!` I'd leave space for future code explicitly, for `panic!("...")` I'd use `expect`. So inlining `unwrap` doesn't help understanding, it always means that `None` is `unreachable!`. I take it you mean for projects where you are the sole developer? I would like to use `.unwrap()` as a terser `unreachable!()`, but I work with developers whose usage of it suggests they think it is more like `panic!()`. You could argue this was one domino in the Cloudflare chain-of-dominos: a team environment where each developer had different ideas of what `unwrap` means. An unhandled config parse failure should stand out like a sore thumb in code review. A warn-by-default lint could help here, with the escape hatches being either `#[allow(..)]` or explicit `expect`, `unreachable!()`, `panic!()`, etc.

for having `from_sorted_iter` (and agreed that it should check sortedness and panic). And for `map_values` and `try_map_values`.

RelunSec: > The usecase of this especially in exports by example you export everything to the crate except myprivfn and PrivateStruct. > > `pub use crate::mymod::*!{myprivfn, PrivateStruct};` Using a denylist like that to define a public API seems error-prone, since it'd be easy to add a new private item and not exclude it. An allowlist seems safer for that purpose.

Considering the following problem: * I have a `BTreeMap<A, B>` * I have a `Fn(B) -> C` * I want a `BTreeMap<A, C>` I currently have two options, to pick from: * `BTreeMap::from_iter(map.into_iter().map(f))` - cpu efficient but memory inefficient: since `from_iter` can't assume the iterator is already sorted, it consumes the entire iterator into a temporary heap allocation, then sorts it, then calls the internal `bulk_build_from_sorted_iter` function (which is very fast). Assuming a `BTreeMap<String, String>` with 10_000_000 entries on a 64bit computer, this is going to cause an additional 457MiB allocation for the Vec however. * `new_map.extend(old_map.into_iter().map(f))` - memory efficient but cpu inefficient: this calls `.insert()` for each item, effectively copying them over one-by-one. This doesn't have any unexpected spikes in memory usage, but each insert is going to traverse the tree to find the correct insert position, over and over. There was some prior discussion about exposing `bulk_build_from_sorted_iter` so we can make our own function that is both fast+efficient: Feature Request] Expose bulk_build_from_sorted_iter in BTreeMap [libs > BTreeMap's from_iter implementation collects all values into a vec and sorts them, before passing into bulk_build_from_sorted_iter. Sometimes, the data comes sorted. For my use case, from_iter is already insanely fast; I am looking mainly to avoid the extra Vec allocation necessary for sorting. Use case is a dictionary of 1mil+ terms each containing some misc info, parsed using a custom iterator (not in contiguous Vec<_> form so I think this can't possibly be compiler-optimized away). This is a… github.com/rust-lang/rfcs #### Make BTreeMap's from_sorted_iter public opened 01:18AM - 02 Dec 16 UTC PlasmaPower T-libs-api Use case: I'm trying to merge `BTreeMap`s, but in the case of a duplicate key, I…'d prefer to add the values instead of ignoring the first. To do this, I was planning on implementing a custom MergeIter, which seems simple enough. However, I encountered one problem: BTreeMap's `from_sorted_iter` is private, meaning that I cannot efficiently use this iterator to merge maps. I think the reasoning behind this being private is that being passed an unsorted iterator would result in a logic error in the BTreeMap. However, it's already possible to cause this in safe code with an unreliable Cmp implementation. If the function is made public, I'd recommend a couple of changes to make it ready for use without other internal functions. First, don't take `self`, but instead start with an empty map. Note that we might also consider just asserting that the map is empty to start with, as I think this change would require either an unnecessary BTreeMap creation or `mem::uninitialized` in `BTreeMap::append`. Second, add `fix_right_edge()` to the end of the function. This change shouldn't cause any problems for `BTreeMap::append` as it's already calling it afterwords. To avoid the discussion about "should it panic, should it be unsafe { }" (me personally would prefer "may panic" over "unsafe"), and since `BTreeMap<A, B>` already gives us `Ord` guarantees, there could be the following APIs (slightly pseudo-code-y): * `BTreeMap::map_values<K, V, F: Fn(K) -> V>(self, F) -> Self<K, V>` * `BTreeMap::try_map_values<K, V, E, F: Fn(K) -> Result<V, E>>(self, F) -> Result<Self<K, V>, E>` This is the first time I'm proposing language improvements like this (also first post in the internals forum), let me know what you think!