profile
viewpoint

bstrie/dcss-mirror 11

A mirror of the official Dungeon Crawl Stone Soup source code repository, updated daily. Please direct all pull requests to the official repository on Gitorious.

bstrie/ephemeris 4

A simple page for displaying astrological ephemeris data. Features page scraping and a procedurally-generated canvas starfield. Uses Flask, BeautifulSoup, and moment.js.

bstrie/luabind 3

Just a disorganized dump of WIP stuff for embedding different versions of Lua in Rust

bstrie/milky 2

Procedurally-generated Milky Way background for the web

bstrie/.dotfiles 1

Linux configuration files and other essentials

bstrie/dcss-playerstatus 1

Source for CDO's player status page

bstrie/24pullrequests 0

Giving back little gifts of code for Christmas

bstrie/activate.mozilla.community 0

Activate campaign site

bstrie/blog.rust-lang.org 0

The Rust Programming Language Blog

bstrie/book 0

The Rust Programming Language

issue commentrust-lang/rust

Prefer new associated numeric consts in float error messages

Yeah, that's the aforementioned case that only shows up in the event of an error, so (AFAICT) that path won't be taken for the new constants since they resolve successfully.

bstrie

comment created time in 2 days

issue commentrust-lang/rust

Prefer new associated numeric consts in float error messages

@estebank :

I think there are other cases where we still use the old mod consts.

I've gone and grepped through compiler/ for std::i8, std::f32, etc. and found no accidental uses there. I also grepped for std::{} (as seen in this issue) and found only a hint message for things like f32::consts::PI etc which only triggers when an item isn't found at all, which won't trigger for any of the new consts. Probably safe to close this once #78431 merges.

bstrie

comment created time in 2 days

PR opened bjorn3/rustc_codegen_cranelift

Prefer numeric associated constants in example

Per their documentation, the max_value() and min_value() associated functions have been superseded by the MAX and MIN associated constants since Rust 1.43 and are considered "soft deprecated", with all uses currently being replaced in the rustc repo.

+7 -7

0 comment

1 changed file

pr created time in 2 days

push eventbstrie/rustc_codegen_cranelift

Ben Striegel

commit sha 4206f9fc16a0fbc8b42fe4c500864686f90e6970

Prefer numeric associated constants in example Per their documentation, the `max_value()` and `min_value()` associated functions have been superseded by the `MAX` and `MIN` associated constants since Rust 1.43 and are considered "soft deprecated", with all uses currently being replaced in the rustc repo.

view details

push time in 2 days

pull request commentrust-lang/rfcs

RFC: Plan to make core and std's panic identical.

All for removing differences between core and std, and for advancing progress toward capturing format string arguments.

For the sake of completeness, one alternative that I've not yet seen proposed would be to introduce a new alternative to panic! with the correct semantics. Obviously this would be a much more drastic step, but risks no breakage whatsoever.

m-ou-se

comment created time in 3 days

issue commentrust-lang/rust

Tracking issue for RFC 2700: numeric constants as associated consts

In my deprecation PR I ran into some obstacles and have updated the issue here with references to new issues and PRs. I'll hold off on proposing deprecation until those are addressed.

LukasKalbertodt

comment created time in 4 days

issue commentrust-lang/rust

Prefer new associated numeric consts in float error messages

See also #73194.

bstrie

comment created time in 4 days

issue openedrust-lang/rust

Prefer new associated numeric consts in float error messages

This program:

fn main() {
    let _ =  3.40282357e+38_f32;
    let _ =  1.7976931348623159e+308_f64;
}

Produces this output:

error: literal out of range for `f32`
 --> src/main.rs:2:14
  |
2 |     let _ =  3.40282357e+38_f32;
  |              ^^^^^^^^^^^^^^^^^^
  |
  = note: `#[deny(overflowing_literals)]` on by default
  = note: the literal `3.40282357e+38_f32` does not fit into the type `f32` and will be converted to `std::f32::INFINITY`

error: literal out of range for `f64`
 --> src/main.rs:3:14
  |
3 |     let _ =  1.7976931348623159e+308_f64;
  |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: the literal `1.7976931348623159e+308_f64` does not fit into the type `f64` and will be converted to `std::f64::INFINITY`

Note the references to std::{f32, 64}::INFINITY; these symbols have been superseded by associated consts at {f32,f64}::INFINITY (https://github.com/rust-lang/rust/issues/68490).

  1. Update the error message to suggest the new symbols

  2. Determine if any of the other old symbols are contained in any error messages.

created time in 4 days

pull request commentrust-lang/rust

Formally deprecate the constants superseded by RFC 2700

For discussing the first-class soft deprecation ideas suggested here, I've opened https://github.com/rust-lang/rust/issues/78381 .

bstrie

comment created time in 4 days

issue openedrust-lang/rust

Allow `deprecated_in_future` lint to specify an indeterminate future deprecation date

In #78335 there was discussion regarding a first-class "soft deprecation" mechanism.

For background, currently the numeric constants in the primitive-shadowing std modules (e.g. std::u8::MAX) have been superseded by associated constants (#68490). The old constants have been "soft deprecated", which is to say that their documentation suggests the new alternatives, but there is no lint or compiler warning implemented to suggest this.

The obvious next step would be to deprecate these constants, but the deprecation lint is warn-by-default, and some members of the libs team are concerned that this is too minor of a change to justify warnings (outside of an edition, anyway).

There is a more gradual change that should be more palatable: the deprecated_in_future lint. This lint differs from deprecation in that it is allow-by-default rather than warn-by-default. It would allow users to opt-in to warnings (useful for, e.g., the compiler itself: #78380). Furthermore this lint has the additional benefit of being as visible in the docs as an ordinary deprecation, which is a primary concern of #68490. It's the perfect middle ground to resolve the tension here.

However, the deprecated_in_future lint is triggered by giving the usual rustc_deprecated attribute a since value in the future. For the purpose of maximum political expedience, it would be nice in this instance to not have to determine an actual specific deprecation date, and merely suggest that it will be deprecated "eventually".

I propose that the rustc_deprecated attribute should be able to accept a since value of "TBD", in order to trigger the benefits of the deprecated_in_future lint without having to commit to a concrete deprecation date.

created time in 4 days

pull request commentrust-lang/rust

Formally deprecate the constants superseded by RFC 2700

Succeeded by https://github.com/rust-lang/rust/pull/78380.

bstrie

comment created time in 4 days

PR opened rust-lang/rust

Update tests to remove old numeric constants

Part of #68490.

Care has been taken to leave the old consts where appropriate, for testing backcompat regressions, module shadowing, etc. The intrinsics docs were accidentally referring to some methods on f64 as std::f64, which I changed due to being contrary with how we normally disambiguate the shadow module from the primitive. In one other place I changed std::u8 to std::ops since it was just testing path handling in macros.

For places which have legitimate uses of the old consts, deprecated attributes have been optimistically inserted. Although currently unnecessary, they exist to emphasize to any future deprecation effort the necessity of these specific symbols and prevent them from being accidentally removed.

+467 -534

0 comment

110 changed files

pr created time in 4 days

push eventbstrie/rust

bstrie

commit sha 7373754f0f3f025d8ae06b9191a2ab01f2bfd3ff

Update tests to remove old numeric constants Part of #68490. Care has been taken to leave the old consts where appropriate, for testing backcompat regressions, module shadowing, etc. The intrinsics docs were accidentally referring to some methods on f64 as std::f64, which I changed due to being contrary with how we normally disambiguate the shadow module from the primitive. In one other place I changed std::u8 to std::ops since it was just testing path handling in macros. For places which have legitimate uses of the old consts, deprecated attributes have been optimistically inserted. Although currently unnecessary, they exist to emphasize to any future deprecation effort the necessity of these specific symbols and prevent them from being accidentally removed. asdfdsf

view details

push time in 4 days

create barnchbstrie/rust

branch : rm-old-num-const-from-tests

created branch time in 4 days

PR closed rust-lang/rust

Formally deprecate the constants superseded by RFC 2700 S-waiting-on-review

Tracking issue for RFC 2700: https://github.com/rust-lang/rust/issues/68490

Previously, the new associated constants defined by RFC 2700 were stabilized for Rust 1.43. At the time it was decided not to formally deprecate the old superseded constants in the same release, in order to give stable users a chance to upgrade before being subjected to warnings. Thus the old constants were "soft deprecated", i.e. the documentation for each item strongly suggested against its use but no deprecation warnings were emitted.

This PR replaces the "soft deprecation" with, er, "actual deprecation", scheduled for Rust 1.49.

+373 -233

10 comments

71 changed files

bstrie

pr closed time in 4 days

pull request commentrust-lang/rust

Formally deprecate the constants superseded by RFC 2700

Given the size of the diff for fixing up the test suite, and since those commits aren't going to need discussion like the stabilization changes will, I'm going to go ahead and extract those commits into their own PR for the sake of avoiding bitrot. I've also stumbled across a place where the compiler is still suggesting some of the old consts, so I'm going to work on fixing that and then get back to this. I'll also go ahead and implement the "indeterminate soft deprecation" I describe in my previous comment, in the hopes that that will assuage concerns about deprecation here. Closing this in the meantime to be kind to the PR queue.

bstrie

comment created time in 4 days

pull request commentrust-lang/rust

Formally deprecate the constants superseded by RFC 2700

Actually, following up on my previous comment, it seems like we're already 95% of the way to the lint I'm envisioning, via the allow-by-default deprecated_in_future lint, which rustc already #[warn]s for. That moves the sticking point here to the fact that there's currently no way to enable that lint for a symbol without specifying an exact version at which the symbol will become deprecated; I think what we want here to break the gridlock is the ability to specify an indeterminate version for deprecation.

I believe that would satisfy all parties here, by both adorning the docs with big obvious notices without bothering older MSRV codebases. The decision of the exact version at which to deprecate these symbols could be left to the future.

bstrie

comment created time in 4 days

pull request commentrust-lang/rust

Formally deprecate the constants superseded by RFC 2700

@jyn514 IMO if the libs team decides that deprecating these types is a step too far at this point, then it suggests to me that we need first-class support for "soft" deprecations that would allow users to opt-in before it becomes warn-by-default. I'd rather implement that (e.g. by adding a new "soft_since" field to the rustc_deprecated attribute) than do a one-off lint just for this.

bstrie

comment created time in 4 days

pull request commentrust-lang/rust

Formally deprecate the constants superseded by RFC 2700

@lzutao If nothing else this PR is helping to uncover a bunch of places where the old constants are being used in the compiler still, if the libs team decides not to accept this then I'll break those commits out and submit them separately, which will make the next attempt to do this even easier.

bstrie

comment created time in 4 days

pull request commentrust-lang/rust

Formally deprecate the constants superseded by RFC 2700

I've got some other tests to fix now, fortunately they look to be ui tests that need their line/character reference numbers updated. And I only did one by hand before figuring out there's a --bless flag to automate that. :P

bstrie

comment created time in 5 days

pull request commentrust-lang/rust

Formally deprecate the constants superseded by RFC 2700

I've updated the tests. I had to be judicious in places: some tests do want to refer to the old modules (for testing e.g. backcompat regressions, module shadowing). Two rustdoc tests referred to the old modules, and being unfamiliar with the semantics of the rustdoc tests I conservatively marked those as #[allow]. The doctests on the deprecated items themselves were given hidden #[allow]s. The intrinsics docs were accidentally referring to some methods on f64 as std::f64, which I changed due to being contrary with how we normally disambiguate the shadow module from the primitive. In one other place I changed std::u8 to std::ops since it was just testing path handling in macros.

bstrie

comment created time in 5 days

push eventbstrie/rust

bstrie

commit sha 295d18842d6545481570547b2517602c46364199

Update tests to remove deprecated num consts Care needs to be taken to leave the old consts where appropriate, e.g. backcompat tests, shadowing tests.

view details

push time in 5 days

pull request commentrust-lang/rust

Formally deprecate the constants superseded by RFC 2700

Looks like this PR is failing because some tests are still using the old constants. Looks like the prior PRs that removed their use from the compiler missed a few. :) I'll clean those up.

bstrie

comment created time in 5 days

issue commentrust-lang/rust

Tracking issue for RFC 2700: numeric constants as associated consts

(It's also worth noting that your specific example of f32::NAN does indeed exist, and the alternative std::f32::NAN would be deprecated by this proposal. It's things like std::f32::consts::PI that wouldn't be.)

LukasKalbertodt

comment created time in 5 days

issue commentrust-lang/rust

Tracking issue for RFC 2700: numeric constants as associated consts

You're preaching to the choir; as mentioned in the accepted RFC, the original RFC text had proposed this treatment for all the float constants. I'd be happy if the libs team decided to deprecate the float shadow modules as well, but in the absence of that decision there's no need to put off deprecating the integral shadow modules any longer. This RFC has gone on for quite long already.

LukasKalbertodt

comment created time in 5 days

issue commentrust-lang/rust

Tracking issue for RFC 2700: numeric constants as associated consts

Unsure if that was meant to be sarcasm, but if you take the time to read the original RFC you will see that the point of all this is that std::u8::MAX and u8::max_value() are both substandard alternatives to u8::MAX that only exist because of extremely temporary technical limitations. When fixing this for the integral types it was natural to preserve symmetry with the floating point types as well. Some people objected to all the constants defined for the floating point types being given this treatment. Since the point of the RFC was to fix the integral types, we conceded so as to avoid gridlock over tangential concerns. The libs team could, of course, decide to change this policy (it would not be out of the realm of possibility to simply amend the existing RFC), but I am not on the libs team. My PR fully deprecates the constants that were superseded in https://github.com/rust-lang/rust/pull/68952 . I'm content to take this one step at a time.

LukasKalbertodt

comment created time in 5 days

create barnchbstrie/rust

branch : deprecate_int_const_mods

created branch time in 5 days

issue commentrust-lang/rust

Tracking issue for RFC 2700: numeric constants as associated consts

As the original author of RFC 2700, I propose the following resolution to the two currently-listed unresolved questions:

  1. "Should the old items be deprecated?" I propose yes. I have a PR here for further discussion: https://github.com/rust-lang/rust/pull/78335

  2. "Should constants from std::{f32, f64}::consts also be made associated consts?" I propose no. As mentioned in the RFC, the majority of the benefit of this change concerns the integer types, which have no analogue to the consts module on the float types. While it remains my opinion that having a stdlib type shadowing a primitive type is undesirable, I think it's reasonable to leave this topic to a future RFC.

LukasKalbertodt

comment created time in 5 days

PR opened rust-lang/rust

Formally deprecate the constants superseded by RFC 2700

Tracking issue for RFC 2700: https://github.com/rust-lang/rust/issues/68490

Previously, the new associated constants defined by RFC 2700 were stabilized for Rust 1.43. At the time it was decided not to formally deprecate the old superseded constants in the same release, in order to give stable users a chance to upgrade before being subjected to warnings. Thus the old constants were "soft deprecated", i.e. the documentation for each item strongly suggested against its use but no deprecation warnings were emitted.

This PR replaces the "soft deprecation" with, er, "actual deprecation", scheduled for Rust 1.49.

+223 -87

0 comment

21 changed files

pr created time in 5 days

push eventbstrie/.dotfiles

bstrie

commit sha a34be7c08af91e1ddb04996b7373885fa85d5cd6

vimrc updates

view details

bstrie

commit sha b8505380a8431a30cb39a53ae61ff52f0eea27f9

Switch from pathogen to Vim 8 packages

view details

push time in 9 days

push eventbstrie/.dotfiles

bstrie

commit sha b1d405208bb8e4b6f3ca58071c57c4b56ebae82d

Remove irssi config Farewell, sweet prince

view details

bstrie

commit sha 39f3e17f16f116ac8b24206ffec35363255cf498

Adjust for repo rename

view details

bstrie

commit sha 14728f14d3bf6fbb98910b0474dee35e4ad2b5c6

Cleanups, preparing to redo vim mods

view details

push time in 9 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

Is that the full list? Looks like there's an issue for that at https://github.com/rust-lang/rust/issues/76738 . In the meantime, what determines the minimum supported LLVM? If, for example, that were the only thing blocking stabilization of this feature, then that may be a persuasive argument to bump the min LLVM. Is that the only blocker? I don't see any others listed...

Amanieu

comment created time in 17 days

issue commentrust-lang/compiler-team

Move the compiler to a new `compiler/` directory

I noticed that this was closed without comment, and meanwhile #316 is still open. Can someone clarify the status?

mark-i-m

comment created time in 18 days

issue commentrust-lang/rust

Tracking Issue for inline assembly (`asm!`)

One of the steps in the issue here:

LLVM version check (#69171 (comment))

Quoting the linked comment:

Let's add a new compile-time feature flag to rustc, something like llvm_inline_asm_ok, which indicates if we have an LLVM that should handle inline assembly without the known bugs we've encountered.

Before anyone could start working on this, they would need a list of these "known bugs". Do we have such a list?

Amanieu

comment created time in 18 days

issue commentrust-lang/rust

min-LLVM: Can only use x86 asm ATT syntax for LLVM < 10 in new `asm!`

As of this writing the minimum supported LLVM version is 8, correct? (I'm not sure precisely where this is documented.) Given that LLVM produces a new major release twice a year, might we reasonably expect the minimum supported LLVM version to increase to 10 by this time next year?

lzutao

comment created time in 18 days

issue commentrust-lang/rust

Tracking issue for RFC 2603, "Rust Symbol Mangling (v0)"

So support for this in rustc is completely implemented at this point, and now we're just waiting for tooling vendors to accept patches? If so, rather than waiting passively does anyone have contacts in the GCC project who we can reach out to to shepherd this along?

Centril

comment created time in 19 days

pull request commentrust-lang/rust

Widen TypeId from 64 bits to 128.

If the concern is users calling transmute with TypeId, could the stdlib specialize transmute<TypeId, U> (along with any other type that's supposed to be an opaque implementation detail) and tag the function to emit a warning when called, with possible deprecation in the future? I'm not sure of the state of specialization, nor am I aware of how it would react to being used on an intrinsic, nor whether the deprecated attribute would work on a specialized function, but conceptually it feels like that would provide for a reasonable migration path.

eddyb

comment created time in 19 days

push eventbstrie/scengen

bstrie

commit sha ec06cc8c05054e5a852b4051d0877f7a0e4f62f5

Slightly refine data

view details

push time in a month

push eventbstrie/scengen

bstrie

commit sha 27f7e49d4360560c891ee06f04c1a984933bdc3e

Rectify highly inaccurate monster desc

view details

bstrie

commit sha 30f8f782161d9dda9106c1054d1b7e633f5c1e07

Fix ogre hd

view details

bstrie

commit sha 96778fa3768d9d06366fc48017b0ae354b83a9c1

Basic code running

view details

push time in a month

issue commentrust-lang/rust

Tracking Issue for `min_const_generics`

Regarding some of the steps listed here:

  • For "const wf (generic params in associated consts)", what is the issue? #74877 specifically calls out that const ASSOC: usize = 64 / N; should work, so is this step about discussing whether or not it should be stabilized, or is it calling out something that hasn't been implemented yet? Can someone with more background open an issue that we can link to?
  • For the second step, can it be checked off now that #74595 is merged?
  • For "fix remaining blocking issues", do we have a list of these, or at least a vague upper bound on how many issues might exist? The F-min_const_generics label only lists three issues including this one, are either of the other two blocking?
lcnr

comment created time in 2 months

push eventbstrie/countess

bstrie

commit sha 2f255cd65ab06ddbf6c23e46b041ade0f75bd912

refactor: minor reorganization

view details

push time in 2 months

PublicEvent

push eventrustacean-station/rustacean-station.org

bstrie

commit sha bf018f1c1f0d8b1e2d2b6cff8220991f68603ded

Add timestamp

view details

push time in 2 months

push eventrustacean-station/rustacean-station.org

bstrie

commit sha ab356cdac7ec6fd3e18353ffc510158e80fbd2a1

Link to detailed release notes for 1.44

view details

push time in 2 months

push eventrustacean-station/rustacean-station.org

bstrie

commit sha 196795029e4cb0c57b4f854fa6d79552df4d8721

Update Cargo link Unix was a mistake

view details

push time in 2 months

push eventrustacean-station/rustacean-station.org

bstrie

commit sha d40baad0a493015d699dc25e9eb83f8964c7cd54

44n45 review

view details

push time in 2 months

create barnchrustacean-station/rustacean-station.org

branch : 44n45

created branch time in 2 months

PR opened rustacean-station/rustacean-station.org

Minor template tweaks

Because remembering which values are and are not supposed to be strings drives me batty.

+3 -3

0 comment

1 changed file

pr created time in 3 months

push eventrustacean-station/rustacean-station.org

Ben Striegel

commit sha 0979720a6a99d292fbc43b0ab719d7389fe9631b

Rust 1.39 episode

view details

Ben Striegel

commit sha acd7bd1fc0f1dfb6aba2a48ee24bf482fbfcab53

Erase list newlines

view details

Jon Gjengset

commit sha 9c2a3c3e4cb1d2927aeb878f44d3826338cc5ec6

Merge pull request #9 from rustacean-station/rust1p39 Rust 1.39 episode

view details

Jon Gjengset

commit sha c77cc7dc1d15bede56aa92288b6b8a2318fbcee6

Merge pull request #10 from rustacean-station/template Template tweaks

view details

Jon Gjengset

commit sha 7a3be573af469b5aff190cfb75b4fe75e6c9585f

Fix name for episode 6 Notice that we _must_ preserve the guid.

view details

Jon Gjengset

commit sha 3114f96cc8ad37de01f8f57ec0ada47b8e68c49e

Stop using double-/ in guid Updates all old episodes to hardcode their current guids.

view details

Ben Striegel

commit sha 1b372fb2243368bd115f622d44d27f2cd20efe82

Add reddit link for 1.39 episode

view details

Jon Gjengset

commit sha 103928becca442348001dc7a021b30a52f4ffa41

Merge pull request #11 from rustacean-station/39follow Add reddit link for 1.39 episode

view details

Ben Striegel

commit sha 8073ace85e2d5f5acdea39f6182fedebfaf5ec74

Episode 8: Zola

view details

Ben Striegel

commit sha 3ba4d3e2d7abebf31e9c9508e6e2622095df37f6

Address comments

view details

Ben Striegel

commit sha fa04d79a6372b95b286377168c1ec440d66ec860

address comments

view details

Ben Striegel

commit sha b3fdda3f3a0cd02613d14a6618f0722463c01c73

Merge pull request #13 from rustacean-station/007 007

view details

Ben Striegel

commit sha f06c67091da389677e8207eda4667899deab48f8

fix date

view details

Ben Striegel

commit sha 8a9f2366daa2e900caef5d8e22d9593e3f789944

Merge pull request #14 from rustacean-station/007 fix date

view details

Ben Striegel

commit sha c4cfd36b8cbba4750c1f0016a39b8cb38ca3aa9d

really fix date tho

view details

Ben Striegel

commit sha dc6c7a231994a70be2712ac46b7dcc61a689a59d

Merge pull request #15 from rustacean-station/007 really fix date tho

view details

Ben Striegel

commit sha fb6af6ddb5d8008046602ef8270e08bf623db73e

Add reddit link

view details

Ben Striegel

commit sha 1e33dc79103aacdf645cc97e2843f53e3bbc116d

Merge pull request #16 from rustacean-station/007 Add reddit link

view details

Ben Striegel

commit sha 8f51b2254ce92832a979a91e9b02bf416c4d5bba

I am a travesty

view details

Ben Striegel

commit sha 60f5f4c7b775efcce8bf1efe4f5a80a7d266ece7

Merge pull request #17 from rustacean-station/007 I am a travesty

view details

push time in 3 months

pull request commentrust-lang/rust

Add `IntoIterator` impl for arrays by value (`for [T; N]`)

Current status: Blocked on #70903 or const generics (whichever is resolved/stabilized first).

Now that we have a concept of min_const_generics, I believe this is only blocked on that rather than on full const generics, yes?

LukasKalbertodt

comment created time in 3 months

Pull request review commentrustacean-station/rustacean-station.org

Ep25: RustFest w/ Katharina & Florian

+---+title: "RustFest 2019 Interview Series: Burnout in Open Source Software; The Rust Roadmap"+date: 2015-07-30T22:00:00Z+file: https://audio.rustacean-station.org/file/rustacean-station/rustacean-station-e025-rustfest-katharina-florian.mp3+duration: "49:03"+length: "35318701"+#reddit: (leave blank on initial publish, amend with link and uncomment this line after Reddit thread has been posted)+---++Two more long-awaited interviews from RustFest 2019: [Katharina Fey](https://twitter.com/spacekookie) on the phenomenon of burnout in software and in open source communities and [Florian Gilcher](https://twitter.com/Argorak) on Rust's annual roadmaps.++<!--+The episode introduction goes here.+The first paragraph should ideally be short, and is used in various+places as a "short description" for the episode. Any subsequent+paragraphs show up as "expanded description".+-->++### Contributing to Rustacean Station++<!-- You can probably leave this as-is -->++Rustacean Station is a community project; get in touch with us if you'd like to suggest an idea for an episode or offer your services as a host or audio editor!++ - Twitter: [@rustaceanfm](https://twitter.com/rustaceanfm)+ - Discord: [Rustacean Station](https://discord.gg/cHc3Gyc)+ - Github: [@rustacean-station](https://github.com/rustacean-station/)+ - Email: [hello@rustacean-station.org](mailto:hello@rustacean-station.org)++### Timestamps & referenced resources++#### [@00:50] Part 1: Burnout w/ Katharina Fey++ - [@01:54] - How common is burnout in software?+ - [@03:24] - How does burnout manifest in volunteer endeavors like open source software?+ - [@08:10] - How does rotation of responsibilities alleviate burnout?+ - [@13:41] - What communities succeed at combating burnout?+ - [@16:44] - Final thoughts on burnout and governance++#### [@19:50] Part 2: The Rust Roadmap w/ Florian Gilcher++<!--

I could link to the 2019 roadmap, I suppose I could link to the 2020 roadmap as well although at the time it didn't exist, so we were mostly just talking about it in abstract, would that be weird?

bstrie

comment created time in 3 months

issue commentrust-lang/rust

Tracking issue for "implicit named arguments for formatting macros"

My preference would be to deprecate panic! with arbitrary expressions and only support format strings. I have never seen a use of non-string panics in the wild, so I think this functionality is better provided by a function in std::panicking that takes a Box<Any>.

When the ability to use arbitrary expressions was originally proposed in 2012, the only rationale given was "in the future it will probably need to accept any sendable type argument, not just a string", so in retrospect it was probably just a mistaken prediction of how the idioms governing its use would evolve over time. I second the idea that panic should just support format strings (the only possible use case I can imagine is as a minor aid for printline debugging, but we have dbg! these days for that).

nikomatsakis

comment created time in 3 months

Pull request review commentrust-lang/rfcs

Edition 2021 and beyond

+- Feature Name: N/A+- Start Date: 2020-07-29+- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)+- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)++# Summary+[summary]: #summary++* Announce plans for a Rust 2021 Edition, and for a regular cadence of editions every 3 years thereafter.+    * We will roll out an edition regardless of whether there are breaking changes.+* Unlike Rust 2018, we will avoid using editions as a "deadline" to tie together high-priority projects.+    * Instead, we embrace the train model, but editions are effectively a "somewhat bigger release", giving us an opportunity to give an overview of all the work that has landed over the previous three years.+* We specify a cadence for Edition lints.+    * "Edition idiom" lints for Edition N will warn for editions before N, and become "deny by default" in Edition N.+    * Since it would be disruptive to introduce deny-by-default lints for Rust 2018 now, the Rust 2018 lints are repurposed into Rust 2021 Edition lints.+* We specify a policy on reserving keywords and other prospective changes.+    * In short, reserving keywords is allowed only as part of an active project group.++# Motivation+[motivation]: #motivation++The plan for editions was laid out in [RFC 2052] and Rust had its first edition in 2018. This effort was in many ways a success but also resulted in some difficult lessons. As part of this year's roadmap, one of the major questions we identified was that we need to decide whether we are going to do more editions and -- if so -- how we are going to manage the process.++[RFC 2052]: https://github.com/rust-lang/rfcs/blob/master/text/2052-epochs.md++This RFC proposes a specific answer to those questions:++* We will do new Rust editions on a regular, three-year cadence.+    * We will roll out an edition regardless of whether there are breaking changes.+* Unlike Rust 2018, we will avoid using editions as a "deadline" to tie together high-priority projects.+    * Instead, we embrace the train model, but editions are effectively a "somewhat bigger release", giving us an opportunity to give an overview of all the work that has landed over the previous three years.+* We specify a cadence for Edition lints.+    * "Edition idiom" lints for Edition N will warn for editions before N, and become "deny by default" in Edition N.+    * Since it would be disruptive to introduce deny-by-default lints for Rust 2018 now, the Rust 2018 lints are repurposed into Rust 2021 Edition lints.+* We specify a policy on reserving keywords and other prospective changes.+    * In short, reserving keywords is allowed only as part of an active project group.++## Expected nature of editions to come++We believe the Rust 2018 was somewhat exceptional in that it introduced changes to the module system that affected virtually every crate, even if those changes were almost completely automated. We expect that the changes introduced by most editions will be much more modest and discrete, more analogous to `async fn` (which simply introduced the `async` keyword), or the changes proposed by [RFC 2229] (which tweaks the way that closure captures work to make them more precise).++The "size" of changes to expect is important, because they help inform the best way to ship editions. Since we expect most changes to be relatively small, we would like to design a system that allows us to judge those changes individually, without having to justify an edition by having a large number of changes combined together. Moreover, we'd like to have editions happening on a predictable cadence, so that we can take that cadence into account when designing and implementing features (i.e., so that we can try to tackle changes that may require migrations earlier, to give plenty of time).++## Key ideas of edition do not change++Just as with Rust 2018, we are firmly committed to the core concepts of an edition:++* Crates using older editions continues to compile in the newer+  compiler, potentially with warnings.+* Crates using different editions can interoperate, and people can+  upgrade to newer editions on their own schedule.+* Code that compiles without a warning on Edition N should also+  compile on Edition N + 1.+* Migration between editions should generally be automated.+* Editions make "skin-deep" changes, with all editions ultimately+  compiling to a single common representation.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++We use this section to try and convey the story that average users will need to understand.++## What is a Rust edition?++Every three years, we introduce a new Rust Edition. These editions are named after the year in which they occur, like Rust 2015 or Rust 2018. Each crate specifies the Rust edition that it requires in its `Cargo.toml` file via a setting like `edition = "2018"`. The purpose of editions is to give us a chance to introduce "opt-in" changes like new keywords that would otherwise have the potential to break existing code.++When we introduce a new edition, we don't remove support for the older ones, so all crates continue to compile just as they ever did. Moreover, editions are fully interoperable, so there is no possibility of an "ecosystem split". This means that you can upgrade your crates to the new edition on whatever schedule works best for you.++The release of a new edition is always a celebratory affair. It gives us a chance to look back at all the work that has gotten done over the last three years. The "opt-in" changes also allow us to introduce new features or syntax that would otherwise be impossible.++## How do I upgrade between editions?++Upgrading between editions is meant to be easy. The general rule is, if your code compiles without warnings, you should be able to opt into the new edition, and your code will compile.++Along with each edition, we also release support for it in a tool called `rustfix`, which will automatically migate your code from the old edition to the new edition, preserving semantics along the way. You may have to do a bit of cleanup after the tool runs, but it shouldn't be much.++## "Migrations" in an edition vs "idiom lints"++When we release a new edition, it comes together with a certain set of "migrations". Migrations are the "breaking changes" introduced by the edition, except of course that since editions are opt-in, no code actually breaks. For example, if we introduce a new keyword, you will have to rename variables or functions using the old keyword, or else use Rust's `r#keyword` feature (which allows you to use a keyword as a regular variable/function/type name). As mentioned before, the edition comes with tooling that will make these changes for you, though sometimes you will want to cleanup the resulting code afterwards.++In addition to those migrations, editions also come with a set of "idiom lints". These lints warn against deprecated patterns that we wish to discourage, even though they continue to work. Since these are lints, they don't cause your code to stop compiling. 

I think this section could be worded to be more clear. When users think of "editions", they think of "the edition that my code is on", not "the highest edition that my toolchain supports". This section appears to be saying that if a user has code on Edition 2018, and they update to Rust 1.XX which supports Edition 2021, their Edition 2018 code will immediately begin to produce warnings for Edition 2021 features, without any form of opt-in being necessary from the user. I think this fact is obscured by language like "editions also come with"; there's either a conflation of editions with toolchain versions that introduce editions, or it may be better served by emphasizing that when an edition is released, the previous edition can be mutated to add new warnings.

This is an important distinction to make because an entirely reasonable alternative formulation could be "when Rust 2021 is released, any code that opts-in to it will be subjected to warnings that will become errors in Rust 2024", which I don't think this section is proposing.

nikomatsakis

comment created time in 3 months

push eventrustacean-station/rustacean-station.org

bstrie

commit sha dea25dc1b071bfd2ae8a1d63bf83018f4a7bcac9

Plausible fake date

view details

push time in 3 months

push eventrustacean-station/rustacean-station.org

bstrie

commit sha 799a86d73a77086a3c72a83f941790a84238b51e

Fix audio link, rename file

view details

push time in 3 months

PR opened rustacean-station/rustacean-station.org

Ep24: RustFest w/ Katharina & Florian

The Florian interview was a bit freeform so timestamps for discrete topics didn't really make sense.

+59 -0

0 comment

1 changed file

pr created time in 3 months

create barnchrustacean-station/rustacean-station.org

branch : cf

created branch time in 3 months

more