Hacker News Reader

Comment by stcredzero | Hacker News Reader

but that's only a comfort for the programmer's ability to reason about the code

A way to mark functions as pure for this purpose would be great! Especially if it's not as fraught as const in C++.

We actually did have this once, but it wasn't really worth it, so it was removed. https://news.ycombinator.com/item?id=6940624 is the HN discussion, but it looks like the link might now be wrong?

It was also a very, very long time ago, and so today's Rust might be different enough that those reasons don't apply any more.

The reason at that point vis that there weren't any practical benefits and that it was preferable to wait for a more general mechanism. The first claim is dubious, but I can empathize with second, as long as it doesn't become tacked on.

Haskell can do cool optimizations that make it feel like magic sometimes.

In some ways, const fn reminds me of this.

Note that a lot of these optimizations aren't necessary in Rust -- e.g. list fusion is only valuable in Haskell because mapping over lists is exposed as a one-shot operation that produces a new list. So `map map map list` is conceptually building 2 whole lists of temporaries you don't care about (and you often don't actually care about the last one either, in cases where you just iterate over it and discard it).

Meanwhile mapping in Rust generally takes an iterator and produces another iterator that will apply the given closure to the current element as it's yielded. So the naive codegen for iter().map().map().map().collect() is exactly what list fusion is trying to produce -- no temporary lists.

TL;DR: making "map" having the monadic `T[U] -> T[V]` signature is really expensive. ¯\_(ツ)_/¯

> We actually did have this once, but it wasn't really worth it, so it was removed.

Ah, yeah I had a vague memory that that was the case, which is why I asked.. I seem to recall it being removed, but I only follow Rust news, don't use it, so I wasn't sure of the reasons or implications.

I think that being able to enforce purity would be fantastic for actors, agents, and/or game loops.

https://news.ycombinator.com/item?id=8609775

It wouldn't help in most of these cases. It'd be too burdensome to require that map/filter/etc. take pure arguments. In the absence of that, the compiler is left with examining the specific function being called, which it can already do as a direct call as long as the body is visible (#[inline]). If the body is visible, LLVM will internally automatically mark the function as pure (readnone) if it is.

const does not imply pure. If applied to a member function, it makes this const; if applied to types it makes types const. Purity is a different concept. The closest match would probably be constexpr.

const does not imply pure. If applied to a member function, it makes this const; if applied to types it makes types const.

You just demonstrated what I mean when I comment that const is fraught.

Purity is a different concept.

Purity more easily maps more closely to an abstract concept and is easier to for people reason about.

Reply on news.ycombinator.com