#rust-lang

ubsan: that's a T-libs issue

yeah

still, very easy to solve

ubsan: it will not be left unsolved obsly

arielby: obviously :P

we just have to tell the discriminant_value people

well

disc_value is still good for

enum Option<T> { None, Some(T) }

disc_value(opt) -> 1 if Some, 0 if None

I wasn't aware it was used for anything else :P

ubsan: sure

but it coincides with C-enum -> int casts

so I say it should coincide with them at char, bool

ah, 'kay

because they are C-enum-like types

sure

that seems fine

I'd still like prim_cast to work on c-like enums, bools and chars

and that means 1 intrinsic rather than 2

turning them into ints

ubsan: what's prim_cast?

arielby: basically, getting rid of the rest of the uses of as

I see casts as

fp->int

int->fp

fp->fp

int->int

which are fp operations and should be intrinsics of their own

[iu]X->[iu]Y

which should be 1/2 intrinsics

isize/usize<->ptr

and

that would be overcomplicated

discriminant_value

imho

3 casts that are FP ops

you want people to actually use these things

with weird semantics and potential failure

if it's an FP op, or an as cast, people will use as

ubsan: I say deprecate `as`

arielby: sure

arielby: we're unlikely to ever get rid of it though

maybe in 20 years

it permeates *all* rust code

ubsan: sure

Rust 2.0 should remove old-style macros and `as`

`x as f32` is still nicer than `prim_cast(x)`

arielby: Rust 2.0 is like, 2 years from now...

ubsan: ?

it allows for much easier switchover

Rust 2.0 is when we accumulate enough deprecated features

we want to clear them all

we don't want python 2->3

we want C++11 -> 14

ubsan: C++11 -> 14 is not a breaking change I think

so it is Rust 1.X -> 1.Y

yes it is

C++14 -> C++17 is also a breaking change

but a *minor* breaking change

ubsan: macros are widely used

macros 1.0 will not be taken out in Rust 2.0

then why will we need Rust 2.0?

struct dropping order

for one

other reasons too

taking out deprecated things is a big one

stuff that's been deprecated in stdlib

ubsan: I think we allowed ourselves to change struct dropping order in a minor

we did worse things

Python does these kinds of things in minors

arielby: we allowed ourself

but we have to allow for back-compat

#[struct_drop_forwards]

or something

then in 1.0, we remove it

err

2.0

so everything drops backward

ubsan: I think rolling deprecation might be a better model

so you deprecate for like 10-20 minors

and then remove

arielby: but rust != rustc

you have to think about multiple compilers

ubsan: but we sync lang changes with the compiler

arielby: we won't be able to once mrustc gets up and running

and we *really* won't be able to once grustc gets up and running

I still want rolling deprecation

and I won't use names like "Rust x.0" for something with that

arielby: well, look at C++

ubsan: its called C++11/C++14/C++17

you get deprecation for 3 year cycle, then removed in the next

exactly

so it is like minors

time-based

yeah

that's what I want

because it's worked in a language we're *very* similar to

and it's also a postspecification

GCC released in 2010 supports most of C++11

like that

right

but removals come after standards

you test in compilers and then standardize; then you deprecate and remove from the standard, then remove from compilers

like, stabilization wouldn't be a thing; you'd standardize and it'd become stable

ubsan: so if you have 120-week cycles

it is like

Rust 1.0X

Rust 1.2X

Rust 1.4X

where, say, rustc 1.32

no

rustc 1.52

supports everything from Rust 1.4X

supports some things from Rust 1.6X under feature flags

and supports all features deprecated in Rust 1.4X, but not features deprecated in 1.2X?

yeah, basically

except we might call them "Rust 2017" instead of Rust 1.2X

except that I'd argue it should be Rust 3.0, Rust 4.0, and Rust 2.0

or that, sure

I don't like going in major versions like that

naming ¯\_(ツ)_/¯

that's fine

s/I'd argue/I'd rather/

that's not the important thing tho

the important thing is what it means

so we can deprecate, say, old-style macros in standards

and then if no-one uses it

we may remove it from Rust 2021 or whatever

yeah

and then the compiler probably supports it until 2024

or might support it forever

if it does -std=17

or w/e

ubsan: eh

or you might just do MSVC model

I thought that each Rust compiler version

has 1 "standard" mode and 1 "draft standard" mode

arielby: the important thing is each compiler gets to choose for itself

but nothing prevents us from having an "old standard" mode

you can either be gcc or msvc

(support everything from the beginning of time or only support the latest thing)

there are benefits and drawbacks to each approach

Rust is currently MSVC

yep :)

which is good, because it's easier to support new features