#rust-lang

nrc: aturon: fyi my internet connection has gone totally screwy at some point during the compiler team mtg. I doubt I'll be able to usefully attend the lang team mtg

:-(

could you dial in, eddyb-style?

I don't dial in

nrc: oh I could look into that

I use mobile vidyo

and turn the camera off :P

the real question is: will I fall asleep before the meeting ends?

tune in to find out!

This was useful: https://mana.mozilla.org/wiki/display/SD/Audio+...

(Currently on the call.)

nrc: ping lang mtg

I can't make it today

aturon: So how *would* -> impl Trait "desugar" to another syntax?

aturon: Re "something has gone wrong": or you have a big complicated type that you don't want to name. :)

I feel much better about `impl Trait` in arg position with the learnability argument

still feel that not doing it simplifies everything so much - in particular it closes off the some/any issue

Ah, trade-offs

nrc: Yeah, same. I'm torn between "learnability" and "what do we want the syntax to look like for people who have already learned".

nrc: I found the learnability argument compelling, and it'd be a no-brainer for me if we didn't already have all the existing syntax.

nrc: What are the chances that we can actually get to the point that we could drop the word "impl" and have "arg: Iterator" mean "arg: impl Iterator" rather than "arg: dyn Iterator"?

Because that'd be even more learnable...

I'm not actually persuaded we would do much differently starting from scratch - we'd still want generic syntax. Best thing we could do would be to not have bare traits be trait objects by default

JoshTriplett: I'm personally not convinced we can, aturon is more optimistic

I think we agree it would need a 2.0 or a new epoch or whatever

It's not obvious how we could without a compatibility break, and I'm honestly quite apprehensive about the idea of a Rust 2.0 in the "Python 3" sense.

IMO, it is the kind of change we should not do, even in a 2.0 because it makes reading 1.0 vs 2.0 crates super difficult

but I think reasonable people can disagree on that

I'm very pro-2.0 in general, but I feel that we have to very selective in the kinds of breakage we can accept in order to avoid a Python 3/Perl 6 situation

and the dyn Trait proposal falls outside of that IMO (unfortunately)

nrc: I've had several people tell me that Ruby managed their equivalent of Perl 6 / Python 3 with minimal fanfare, specifically because they had very *few* simultaneous changes.

nrc: The argument was effectively that Python 3 did too much, and that a quick break of a small and critical set of issues (such as Ruby's "thou shalt Unicode") was doable.

That's part of what makes me apprehensive about Rust 2.0; if it becomes the repository of the 47 things we want to break, as opposed to the 2-3 we *have* to...

i think it's also that rubyists were more used to upgrading

perl 6 is a completely different language

python is more conservative than ruby

(as someone who lived through that particular transition)

ruby also did some things to make it easier

steveklabnik: Such as?

I don't think it is the number of things, so much as the magnitude of them

i'm thinking of the encoding stuff

nrc: Fair enough; "pervasive", then.

if they are kind of 'only technically breaking changes' I think we can be OK

also, i think most rubyists had a great reason to upgrade: the interpreter was _entirely_ re-writtne

python 3 is not widely considered strictly better

and that's hurt it too

e.g., ergonomic match or the lifetime elision change (for opposite reasons)

steveklabnik: I think if Python 3 had *just* been the "everything is Unicode now" release, without the several dozen other things, it would ahve gone over better.

yeah, Rust 2.0 would have to be compelling as well as incremental