#rust-lang

wow, 95 hoorays on the NLL RFC already :)

yeah it's gotta be a record

also the ratio of emojis to comments is pretty funny :)

Ralith: the syntaz we uss btw is match x { y: T => ..., z: U => ... } when discussing such features

type ascription *almost* made it into the language

yeah, that's the one I used

the absence of type ascription is weird

I would love to see type ascription show up while deprecating `as`

scottmcm: I wanted to remove literal suffixes before 1.0

suffice to say I failed

scottmcm: deprecating for coercions, right?

I do not want more than what let x: T = expr; does to happen for let x = expr: T;

I would be fine with deprecating totally, assuming new functions like .wrapping_cast() and such

oh

I don't know how I feel about that

correct numerics code is unergonomic as it is

I recall a comment that seemed reasonable about "it'd be odd to have two infix conversion operators"

but just deprecating the ones that are implicit would also be a reasonable plan, and much less noisy

well, coercions are intentionally distinct from conversions but one might argue they shouldn't

Deref can be thought to "throw away information" just like a truncating cast so idk what makes me want to keep the distinction

But I also come from the C++ "it's better to have really long conversion methods" camp

welp

(for things that aren't reversible)

I still want a solution for complex number code

custom operators would please me

Like a @ or #

I'd rather write +% than take a dozen characters

there was that thread about allowing `a \dot b \dot c`

that is useless for me

Matlab has a +.

it's the length of the method names

that is the problem

But that might not work well with floating points

eddyb: which ones? the checked_add and such?

they're usually far longer than variable names

hmm, point

scottmcm: wrapping_add, saturating_add, overflowing_add are the ones I use

the first two should suck less to write

hardware not having saturating ops decades ago was a mistake

I made ugly C++ code with footgunish comparisons very clean Rust code by using saturating ops

actually

I want a projective integer type :(

projective?

integers are already circular-ish

just make INT_MIN the point at infinity

Kind of like a +/- Inf

yeah

now you have a symmetrical value range

*and* that infinity swallows things that would over/underflow

and keeps them in an easy to check location

eddyb: that feels a lot like checked_add

INT_MIN as NAN, with +/- INT_MAX as +/- INF?

cbreeden: no, saturating

but

Where None is your projective inf

the problem with saturating ops is if you hit the cei

cbreeden: aaah sorry

you mean like Option<i32> + and_then composed with checked_add

scottmcm: why?!

because which side the Nones go is so arbitrary

min and max have very different None behaviour

well

if you want min/max to ignore None I agree

eddyb: at least Try will allow `catch { a.checked_add(b)?.checked_add(c)? }` to make part of the math problem better

heh

+?

In before a? +? b? Is a valid expression

I'm looking forward to const generics so that Integer<A,B>+Integer<C,D> -> Integer<A+C,B+D>

scottmcm: so NAN doesn't seem as useful as infinity to me

eddyb: INF-INF, though

because only 0 / 0 is NAN with integers

ah that too

scottmcm: well NAN introduces more problems than it solves

just make the point at infinity handle the NAN case too aaand I just reinvented None

I guess with circular you just define INF +/- INF as INF?

not sure

oh

wait hmmm

a type that's like iN but reuses the MIN as a built-in None does sound interesting

scottmcm: anyway point at infinity is from unums 2.0

since Option<iN> is so space-inefficient

if you're curious

those are better than the very-debunked first ones

?

just to be clear

you mean kahan by very debunked, right?

unums 3.0 are interestingly better but unums 2.0 are an insane deadend

aturon: where to post comments on your blog post?

not read it yet, but about to

thx!

you bet

that someone might eventually put in silicon for its few redeeming properties

waaait a second

unums 2.0 can be convertible to unums 3.0

like, both formats could work in tandem

scottmcm: we should take this else though lol

Well, I'm leaving to go eat in 7 minutes. But I'd be glad to continue it later :)

(here or elsewhere)

NLL up to 109 hoorays now :)

* This RFC is way too long, I'll just leave an emote *

I'm sure that's part of it

aturon: ^ the secret to not get slammed with comments

Though it was also blogged about and Pre-RFC'ed, so...

cbreeden: lol

lol @ "I’ve rarely hated anything as much as I hate the module system proposal"

nrc: btw, the proposal in the post contains several improvements from our previous discussion, and in particular i realized that it *does* make some non-trivial simplifications of the privacy system

I've been shaking my fist at the privacy system a bit today when refactoring one of the RLS crates

also it's quite a bit shorter than the last one :)

minor point: killing `mod` makes it hard to demo privacy in playground examples.

(But something like "anonymous modules" -- maybe rebranded "explicit privacy fences" -- would be a totally reasonable thing to have anyway)

scottmcm: inline mod is another question

aw, I liked the `use ... from ...;` syntax more than `from ... use ...;` JS > Python :-)

nrc: I'm ambivalent

sorry, very bike-sheddy

super-bikeshed: block indenting `from a use {b, c, d};` will look better than with use/from

JS is most certainly not > Python :P

aturon: can we deprecate `super` in use paths?

nrc: not without replacement

:-(

can't you always use an absolute path?

I use super in my code and always feel a little guilty

nrc: ah yes but I think we want some form of super

'from .. use SomeType' maybe

I'd be interested to see where people actually use `super` in paths today - it seems a pretty stylistic choice

I imagine it is used more in crates with deep module hierarchies

I'm totally +1 on the `use` stuff

I would like to do something much more radical with privacy

nrc: "use super::*;" is great for test moduels

*modules

that's probably the only time I use super though

oh yeah, true, I forgot about that