Skip to content
This repository has been archived by the owner on Oct 9, 2018. It is now read-only.

Latest commit

 

History

History
167 lines (130 loc) · 9.61 KB

2014-10-07.md

File metadata and controls

167 lines (130 loc) · 9.61 KB
Raw

Agenda 2014-10-07

Attending

pcwalton, aturon, acrichto, nrc, zwarich, brson, steveklabnik

Status

  • brson: 0.12.0 release, automation
  • acrichto: static vs const, cargo registry owners/authors

Action Items

Friend of the Tree

Alexis Beingessner (aka @Gankro) began contributing to Rust in July, and has already had a major impact on several library-related areas. His main focus has been collections. He completely rewrote BTree, providing a vastly more complete and efficient implementation. He proposed and implemented the new Entry API. He's written extensive new documentation for the collections crate. He pitched in on collections reform.

And he added collapse-all to rustdoc!

Alexis is, without a doubt, a FOTT.

release/debug configure flags

rust-lang/rust#17665

  • nrc: Even if we require 2-3 flags for an optimal build, I feel like that's too many. One word is ok -- anything more is a barrier to entry and an inconvenience.
  • nrc: We discussed various options last week. E.g. turning off logging for release builds on Windows, parallel codegen etc -- there are even more options now.
  • nrc: The question is how to provide simple profiles.
  • nrc: I would like to not allow ./configure by itself; you'll either have to pass debug or release
  • nrc: That would give a good experience for both developers and distributors
  • brson: It's not a standard thing to require an argument to configure, so we might get some pushback.
  • acrichto: I've warmed up to this, but I think we shouldn't require a flag; by default you'd get debug. That way we work in the standard way.
  • nrc: That's the alternative -- making one the default. The question of which should be default is hard. I think strcat is right that, although far more people will use rust for dev, it's not so important if they get long build times.
  • pnkfelix: What if we made the default that, if you don't provide a flag, we announce loudly that the default is being used. In either scenario, we're educating users.
  • nrc: If we have a default, I think we should do that.
  • nrc: What makes me sympathetic to acrichto's perspective is that it's what LLVM does. But I don't want to rely on packagers to ensure that people have a good experience with Rust
  • acrichto: It would be a shame if, when you first try to contribute to Rust, the first build takes an hour when it could have taken 20 minutes.
  • acrichto: Easing the experience for new users is the most important case.
  • nrc: Ultimately, we'll want new users of Rust even more than contributors, so the defaults should cater to them. I worry about people benchmarking on default configs
  • pcwalton: I think about half of the published Rust benchmarks don't have optimization
  • acrichto: But people will very quickly find this out -- asking whether you optimized it.
  • brson: Don't have a strong opinion, but following precedent (LLVM) seems wise.
  • pcwalton: FWIW, Firefox defaults to Release
  • nrc: What does GCC do?
  • pcwalton: Not sure if the question even makes sense there
  • acrichto: It is true that, if I grabbed GCC and built it, I'd expect it to be fully optimized
  • acrichto: Ok, let's set it to release by default (have modes "develop" and "release") and have a warning printout at the end of ./configure if it's using the default
  • brson: How do these umbrella flags interact with others?
  • nrc: Any other explicit flag would override it.
  • brson: So what are the flags, concretely?
  • nrc: Default is "release". I'd prefer "develop" to "debug".
  • acrichto: debug controls debuginfo
  • brson: We have a switch for turning on debug mode, one for debug info
  • acrichto: In Cargo, you either have [missed] or debug info
  • nrc: For the Rust compiler at least, we want to be able to make these fine-grained choices
  • nrc: Develop/debug would imply faster build for lower quality code
  • pcwalton: I slightly prefer debug, because of precedence. Don't really care.
  • nrc: There wouldn't be a release flag, since that's the default
  • pnkfelix: You want a flag, to avoid the message
  • acrichto: --enable-debug
  • pnkfelix: That precedent holds even for umbrella flags? I'd prefer just --debug [ some discussion about --disable-debug ]
  • nrc: So, we'll do this, with release by default, and --enable-debug. I'll update the issue with the plan, and maybe implement.

how to link to RFCs

rust-lang/rfcs#360

  • pnkfelix: When people want to link to an RFC from the Rust repo, sometimes they link to the PR, while I link to the document itself. The link to the RFC document can become stale (when it becomes active). But the link to the PR won't link to the official document.
  • pnkfelix: So, what should we do?
  • acrichto: I've run into this in the past, and worried about it.
  • brson: Could change active/complete procedure.
  • pnkfelix: We could also update the PR to point to the most recent document.
  • brson: There are some other changes we might want to make -- like the RFC numbers not matching the PR numbers.
  • acrichto: The problem with linking to the PR is that it's not really the official document -- lots comments, etc.
  • brson: The PR discussion won't be very interesting later on down the road -- you care about the RFC text.
  • aturon: What about just distinguishing active/complete via a list -- say at the bottom of the README?
  • brson: So should we move the rfcs out to the top level?
  • [missed]: it's nice to have them nested, so they don't dominate the github display pnkfelix to write RFC to: use PR numbers, merge into one directory, use README to track active

Unsafe / raw conventions

rust-lang/rfcs#240

  • aturon: conventions RFC from stabilizatino process. Existing API's inconsistent about where methods on raw reprs go. Sometimes they are methods, like from_raw, sometimes in raw submodule. Proposal is that unsafe methods aren't special cases so should live where methods live, so unsafe constructors should be static constructors on the type. Unchecked variants should use _unsafe suffix, or use use term 'raw' when converting between raw representations. Remaining use case for 'raw' mods is for defining 'raw' types.
  • brson: what about issues of exposing internal representations through 'raw' methods
  • aturon: out of scope for this RFC
  • brson: what are examples from std for remaining 'raw' use cases
  • aturon: core::raw defines underlying representation of language types. sync::raw provides basic low-level types
  • acrichto: ctors of slices and str slices go where? can't be static methods
  • aturon: want to allow inherent methods on built-in types
  • acrichto: e.g. [T]::ctor? (with incredulity)
  • aturon: (you can do this with UFCS: <[T]>::ctor)
  • aturon: may have to be special cases. don't think those ctors justify a submodule. for built in types we may have to provide free functions.

What do we call this group?

  • brson: When we refer to the present group -- which is largely the one responsible for making decisions -- we don't have a name to use! We have the notion of the "core team", but most of the time it's this group that we want to talk about. What's the name?
  • pcwalton: ISO Rust committee!
  • pcwalton: More seriously: The Rust Team
  • nrc: I think if we formalize it, that would work
  • pcwalton: Rust Contributors, Rust Team, Core Team

Remove virtual structs

rust-lang/rfcs#341

  • aturon: want to remove. Wrote this RFC.

Add keywords

rust-lang/rfcs#342

  • acrichto: reserve abstract, final, override
  • brson: I will merge

uint -> uintptr

rust-lang/rfcs#161

  • aturon: thought we were going to write up something on our stance here
  • brson: so we're in agreement?
  • zwarich: ww notes doesn't seem like it
  • pcwalton: issues are: want arrays to be large enough to cover address range; and arrays indexable via int.
  • acrichto: default integer has to be int.
  • brson: mildest form renames 'uint' and 'int' to indicate they are pointer sized, but then you have to decide what to call the default int.
  • pnkfelix: should the guide be promoting i32?
  • pcwalton: no, don't prematurely optimize
  • zwarich: C gets away with platform-defined sizes because it allows automatic conversions. in rust you would have to allow at least some.
  • pcwalton: how do you index in java?
  • pnkfelix: may insist that arrays are 4 gigabytes
  • brson: leave this open until somebody writes a definitive statement?
  • pcwalton: yes

... blathering ...

  • brson: why isn't it tenable to have i32 be the default but uintptr/intptr for indexing?
  • acrichto: difficult to know the impact

example of where library is using int for its backing storage (instead of more efficient i32/u32) rust-lang/rust#16736