#rust-lang

eddyb: I'm definitely super-excited about all the people now coming up with safe interfaces for low-level stuff. as I keep saying, the most powerful part of rust for me is the expressivity of its type-system -- the amount of things you can give safe interfaces to. I was impressed by iterators and interior pointers, turns out that was just the start. now we have pinned memory and (likely) interior collections. what's next?

(that was replying to a think you hightled me in, which may have been some days ago... sorry^^)

I also love how "this library is safe to use" is something that both is easy to understand and has a precise formal meaning.

reem_: Hey there!

reem_: I pinged you on some of your repositories-- oh I see mbrubeck pinged you about it yesterday evening already. It would be really appreciated if you added maintainers.

Or we will need to fork all your stuff, which would be unfortunate.

RalfJ: I think GATs will be the massive new enabler here

I think it will even be possible to define an Arbitrary trait which you can impl for &'a T where T: Arbitrary; which will be pretty cool

centril: GATs enable lots of things but will safe abstractions over dangerous operations be among them? Arbitrary is safe all the way down

rkruppe: Arbitrary for &'a T is impossible right now ;)

sure

rkruppe: GATs will enable you to have a better refl encoding that works for all functors, so that is making the safe abstraction over something unsafe better

but it seems this is partly due to a lack of expressivity _in general_ (not specifically related to making unsafe stuff safe) and insofar it's not possible to "do it safely" it's just the price we pay for having &T in the first place

whereas for example self-references normally require unsafety if it's possible at all, period, and now rust can do it safely

rkruppe: So I think GATs will mostly give you unification and flexibility for already existing safe interfaces over unsafe code

but it is a massive boost in expressivity of the type system in general

which will help low level code

as well =)

(low level == bare metal here)

rkruppe: in any case, yay for GATs :P

yeah :)

rkruppe: HKTs would be also nice so you can have those sweet sweet adjunctions F -| G

est31: yeah no, people intentionally sticking with try! is probably not a concern of mine ;)

centril: thanks to attitudes like yours, rust is becoming less and less a stable language

and more one of those moving target crap things

like those javascript frameworks where if you start using one, it gets outdated the week after

chill

why should I use the 2018 epoch at all

est31: that's... a lot of hyperbole?

also wtf is this about? did i miss an rfc?

rkruppe: try { .. } expressions

centril: why should I opt into the 2018 epoch

The current semantics of catch { … } are IMO super bad.

who guarantees me that it will mean anything

est31: do you want dyn, GATs, const generics, etc.?

in 1 year you might say "scrap rust, use typescript instead"

centril: const generics hahahaha

The part where catch { foo? } == foo instead of catch { foo } == foo.

as if they will get added to the language ever

and even if

they certainly wont make it till the 2018 epoch

est31: i don't know what issues you have but it seems at best tangentially related to the try {} rfc

centril: I *really* dislike that we will need to opt in new epoch for things that shouldn't require a new epoch.

at least given all of the statements by people on this

anyway I dont want to get distracted

breakage = shit

no breakage = leet

2020 epoch might have entirely different patterns altogether

didnt sign up for any of this shit

est31: I somehow read "leet" as "leek" and was super confused.

but its free so I better shut up I guess... not my money you are wasting

est31: again; this is a lot of hyperbole. given rustfix, it will hopefully be trivial to switch up to a new edition

not if you cant use rustfix because it introduces ? everywhere

& you cant turn it off

centril: Where is rustfix?

nox: what do you mean by 'where' ?

again, why should I switch to the 2018 epoch? Why not wait until there is a 2020 epoch with its own set of breakages?

or a 2022 one

centril: I was under water for a few weeks, so did rustfix happen when I wasn't looking?

est31: "why should I switch to rust 1.25? why not wait until there is rust 1.28"?

rkruppe: That's different.

est31: the only substantial thing I could tease out so far is that you don't want rustfix to rewrite try!() to ?, in which case it seems like a small feature to request from rustfix developers or even hack in yourself

nox: the status for 2 april is "not started" but it should be done by the launch of the new edition hopefully ;)

centril: I have trouble believing it will be ready in time, hope I'll be wrong on that.

nox: *crosses fingers*

lol nox

est31: don't attack other contributors nor javascript frameworks. come on.

est31: You should opt in Rust 2018 to have a non-broken implementation of derive(PartialOrd) /s

nox: what things are you thinking of re- shouldn't require an epoch?

steveklabnik: Everything that isn't introducing breakage.

then i'm confused as to what you're talking about

est31: honestly, if all I did was focus on what can be reasonably described as trivial lexical syntax differences, I could absolutely 100% not use Rust; it is has radically different syntax, but I am able to use both Rust and Haskell despite these differences

because you shouldn't have to?

steveklabnik: centril was implying I should.

steveklabnik: I was replying to "14:08 <centril> est31: do you want dyn, GATs, const generics, etc.?"

ah, well dyn has *some* breakage. but is still usable on 2015. the other two are also not epoch-specific as far as i know

nox: well, it is possible that some of these might be in edition 2015 ofc

https://internals.rust-lang.org/t/should-we-res... implies async/await would be 2018-and-later-only

async/await isn't introducing any breakage, right?

the macros 2.0 version works right now

Oh, as keywords, ok.

rkruppe: yes; the draft keyword policy we made yesterday was that; see: https://paper.dropbox.com/doc/Keyword-policy-Sm...

nox: basically: new features with keywords => real keywords, old features => contextual

but there is the option of having them as contextual keywords in the old edition

[union, dyn] => contextual, new stuff => real

centril: Current async/await uses neither for now.

so in that sense the breakage is not inherent

rkruppe: right; but it seemed like we wanted to opt for less maintenance

i'm not trying to dispute the decision

rkruppe: sorry, im just clarifying / relaying the info =)

i'm just saying these are features that could work perfectly fine in 2015 but the team(s) decided not to support them there

I'm not either, I'm just super worried about new features landing in new epochs only just because epochs exist at all.

y'all stop saying epoch :P my brain is going to melt ^,-

This is IRC.

est31: also fwiw thanks to raw identifiers you don't *need* to rename anything for the new epoch (though the invocation does get longer, `r#try!()`)

that would make try a tad too ugly

I'll probably just end up renaming try to dry or tri or something

and then using that in try's stead

if the RFC is going through with breaking try!

it's already ugly :P

steveklabnik: the web is actually quite nice. stuff is being deprecated only very cautiously and only if it doesn't break a ton of stuff

it is open sourced, standards based, multiple implementations exist

that's awesome

centril: Why try instead of catch anyway?

I just have issues with the pace of the mainstream of the ecosystem that runs on the web

There is precedent to use catch, and try is even more reminiscing of exceptional terminology than catch.

est31: all of that is way better than "you are runing rust and javascript is bad"

that's an actual opinion, not an attack

nox: exceptional terminology is morally right, and familiarity is important, + brevity, + inverted order of like 27+ languages is a bad

No it's not.

And there is no inverted order given there is a single block.