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

Latest commit

 

History

History
211 lines (171 loc) · 15.9 KB

2014-06-24.md

File metadata and controls

211 lines (171 loc) · 15.9 KB
Raw

Agenda 6/24/2014

Attending

jclements, Luqman, zwarch, brson, cmr, steveklabnik, acrichto, dherman, jack, felix, aturon, pcwalton, bjz, nrc, huon, azita

Action items

Status

acrichto: toml parser, cargo on windows, cargo.io infrastructure cmr: rebasing, lexer things, grammar aturon: taking PRs on conventions doc, stability dashboard, mem management for lock-free data structures pnkfelix: nonzeroing dtors pcwalton: burning down P-backcompat-lang issues nrc: DST traits

Friend of the Tree

jakub-, otherwise known as Jakub Wieczorek, has recently been working very hard to improve and fix lots of match-related functionality, a place where very few dare to venture! Most of this code appears to be untouched for quite some time now, and it's receiving some well-deserved love now.

Jakub has fixed 10 bugs this month alone, many of which have been long-standing problems in the compiler. He has also been very responsive in fixing bugs as well as triaging issues that come up from fun match assertions.

Jakub truly is a friend of the tree!

  • clapping

Older RFCs ( https://etherpad.mozilla.org/RPT2iP80Iq )

RFC PR 17 (Iterable, rust-lang/rfcs#17 )

  • acrichto: This is one we might want to wait for erickt to be here. I know some others were talking a lot about it. I thought the general conclusion was this is going to be ugly unless we have associated types.
  • aturon: That's one of the downsides. There's also a large family of traits, it's not clear it's the right design.
  • nrc: Let's wait for erickt

RFC PR 88 (Macro to count sequence repititions, rust-lang/rfcs#88 )

  • nrc: What it says on the tin. No discussion for a while. Seems mostly positive, needs someone who really understands macros to comment.
  • pnkfelix: The RFC as written uses a very special syntax for the arity count : $#($x). In the discussion thread people mentioned using a macro-invocation syntax instead, i.e. arity!($x ...). I have not seen an argument for why arity! is insufficient and the specialized sugar is strictly necessary (just arguments for why the latter would look nicer).
  • brson: It sounds like we're not in a position to accept this RFC.
  • pnkfelix: Should push back and see if a macro can suffice, or show why it can't.
  • nrc: To me it sounds like something we want one way or another. Simon has said he's wanted it for Servo.

RFC PR 91 (Coercible/HasPrefix, rust-lang/rfcs#91 )

  • nrc: Niko has been thinking a lot about this, not sure if we want to do anything about this RFC.
  • pcwalton: Postponable.
  • zwarich: Isn't there a higher level coherence problem with coercions, like if you have a coercion from A to B and B to A (?) they should have some relationship in the type system.
  • dherman: The brief answer is yes, there is a concept called coherence that has some algebraic properties you'd ...
  • brson: This is clearly a topic that we care about, but not one we want to think about for a while.

RFC PR 107 (Bind by move, rust-lang/rfcs#107 )

  • zwarich: Currently if you have a match arm that binds by move as opposed to binding by reference, it disallows you from having a guard on that pattern. kmc bumped into this writing an html5 parser. (details from the rfc)
  • zwarich: Niko made a comment that this has some interaction with removing zeroing flags but I don't quite understand it and he's not here to comment.
  • pnkfelix: I'm thinking about it in terms of failure when the predicates run, but I'm not sure that's what it is.
  • pcwalton: It seems fine to me... it's hard to find what Niko was thinking. Could put it behind a feature gate.

Removing f128

  • acrichto: We support enough to tell LLVM that a variable is an f128. You might be able to have a literal for it, but certainly not in the entire range f128 supports. You can't print it. The support for it is so small. It's getting to the point where the burden of having f128 is more than the benefit of having it.
  • brson: The only one who objected last time is huon.
  • huon: I don't see why we need to remove it, there's only one instance of it ("that lint" -- ??).
  • acrichto: It seems like a weird half-baked feature to have in the compiler.
  • huon: ...
  • ...
  • zwarich: f128 isn't supported across all LLVM backends in sane ways. There are ABI issues with it. There's no usecase for it, you can't do anything with it, seems pointless to have a primitive type like that at this point. The applications in numerical analysis is debugging algorithms that have precision errors with double precision, but we have so many missing things that you'd want for numeric code that this seems ....
  • huon: You've convinced me, I no longer oppose removing it.
  • brson: Any other objections?
  • crickets
  • brson: Does this need an RFC?
  • acrichto: Since it's beind a feature gate, no.
  • brson: I also agree that this will break essentially no code.

RFC PR 111 (Index traits, rust-lang/rfcs#111 )

  • pcwalton: There's some bikeshedding here, but it seems like we can start with three [traits].
  • acrichto: This is setting a precedent if we ever want to add += that we're going to have a separate trait per operation, rather than putting it in the same trait.
  • pcwalton: [...] that would affect Index vs IndexSet I think?
  • pnkfelix: Is there ever a usecase for expressing that one is supported but not another, analogous to separating + and +=?
  • pcwalton: [...] you're right that you lose the ability, if you have a data structure where you don't allow mutable references to the inside, but allow setting things (like a hypothetical CellArray, which is an array of Cells). On the other hand I don't know what use case that would satisfy, because you could just make an array of Cells if you wanted that.
  • bjz: Does this interact with Niko's trait matching reform?
  • pcwalton: No, not in the default method solution.
  • pcwalton: Can start with the two minimal traits, Index and IndexMut, mirrors Deref and DerefMut. It won't work with hash tables though.
  • acrichto: That is a little unfortunate, that we won't be able to use the set syntax for maps.
  • pcwalton: We can always add the trait, or a method. I honestly don't care, I just want to close the P-backcompat-lang issue.
  • brson: Let's do that.
  • pcwalton: Resolved: Index and IndexMut, and we reserve the right to add IndexSet, either as a separate trait or as a defaultable method in the future.

Meeting notes

  • cmr: Meeting notes live on the wiki, editable by anyone. They expose no easy way to look at the history of the page.
  • cmr: There's a huge number of meeting notes pages on the wiki. They need to live somewhere; I propose a repo in the rust-lang org.
  • cmr: Then, we can use directories to categorize them (triage, rust meetings, etc).
  • cmr: Also gives us permissions on who can edit the history.
  • acrichto: It seems nice to have all the meeting notes in one location.
  • dherman: We've been doing this for 1.5 years in TC39. It's been hugely successful.
  • steveklabnik: You can export the wiki as a repo of markdown files anyway. The transition is almost painless.
  • acrichto: What would the repo be called?
  • cmr: notes or meeting-notes? minutes?
  • acrichto: Any objections? [ none ]
  • acrichto: I'll set up the repo.

Line length conventions

  • acrichto: This came up in a PR recently. We never really discussed this formally. I want to suggest we have a recomended length of 80 characters, and a hard limit of 100 charachters. Not sure there's precedence for this, what do others think?
  • pcwalton: I don't like the idea of having a soft and a hard limit. Any formatting tool is going to have a hard time with "probably" rules. In a world where we have rustfmt, I don't think this is a good idea. I feel that there should be a limit, and it should be a hard limit. But, keeping old code in its existing style is fine until we have a format tool.
  • dherman: What purpose does the soft limit serve?
  • nrc: I think the idea is that you try and get 80 if you can.
  • dherman: I know what it means, but not why
  • steveklabnik: There's a tension between old people like me who will cry out "you can rip my 80 columns out of my bloody fingers." and younger ones who say "why care about line lengths when my monitor is 40 inches" [...]
  • zwarich: The other problem is that you can't write a lot of rust code in 80 columns. We have 4 space indents, and pattern matching that requires a double indent before you can write any code. The place is when I've seen it offend people is when the comments go all the way to 100 columns.
  • dherman: Doesn't our lambda style also force rightward drift as well?
  • pcwalton: I think it's fine to have a rule that comments have to have a stricter line length restriction, and that's totally fine, tools can handle that. My main thing is that I don't want truthiness.
  • dherman: More than tools is the [...] failing in our duty to end disputes because the rules left wiggle room to keep arguing.
  • nrc: I disagree with that, in the real world you have [...]. If you have a line that is 80 characters long and you need to put a semicolon at the end it's stupid to break it. We do this in Gecko [...]. Having a hard limit enforced by a tool and a soft limit enforced by recomendation is fine.
  • pcwalton: [...] I think it should be longer than 80.
  • dherman: I feel like we're past those days.
  • [...]
  • nrc: If you look at the compiler 90% [...]
  • zwarich: The point of having a style guideline is to resolve aesthetic disputes mechanically.
  • pnkfelix: would having an attribute, e.g. #![linelength80], for telling a tool that the input file adheres to the soft limit, would that help? [ ... ]
  • pcwalton: [....] it seems like a shame to go back to that just for historical reasons, when my plan all along was when rustfmt is working, we run it on every file in the tree, and then rustc will be 100 characters.
  • acrichto: [...] I was mainly [...]
  • dherman: I feel like if we really want to go to 80 characters, we'll need to revise a lot of our other decisions like 4-space indent, indenting in match, hanging [...] in lambdas.
  • zwarich: I agree with Dave, I prefer 80 columns, but everything else in the language forces you to go longer if you want descriptive variable names. It's really tough.
  • brson: Alex, are we trying to make a specific decision about this today?
  • acrichto: I want to solidify our guidelines.
  • pcwalton: [...] I'm not inclined to revist that decision.
  • brson: I'm inclined to agree.
  • [...]
  • acrichto: Let's punt until Aaron has the official guidelines.

Cross-borrowing

  • pcwalton: I want to remove it.
  • nrc: Didn't we talk about this last week?
  • pcwalton: Maybe. [ ... details about having minutes, the decision being documented, tons of discussion last week ... ]

+ on strings

rust-lang/rust#14482

  • brson: I think we should add it, we've been too authoritarian about our decisions recently.

  • [ ... ]

RFC PR 109 (Removing crate_id, rust-lang/rfcs#109 )

  • acrichto: Updated recently with the radical decision of no longer putting hashes in filenames. rustc will not do this, but the build system will still do it.

  • brson: Is this going to break everybody?

  • acrichto: It will break in that the crate_id will be gone, but all libraries discoverable by the compiler today will be discoverable by the compiler tomorrow.

  • brson: [ ... ] Is this going to break the lib.rs convention?

  • acrichto: The short answer is no. I talked about this with wycats, cargo wants [...]

  • brson: [ ... ] Does the compiler still accept a crate name?

  • [ ... ]

  • brson: Does anyone else have comments about this? This is a major change, and we can't keep making huge changes to our versioning. This essentially removes our handling of versions and punting it to cargo.

  • pnkfelix: so if someone who desires Rust's promise that it allows deployment of multiple versions of the same library -- is that person forced to use Cargo?

  • brson: rustc gives you the tools.

  • acrichto: [...]

  • [ ... ]

  • steve: If cargo gets good enough fast enough, [...]. Turns out, the problem is hard.

  • brson: Disagreements?

  • pnkfelix: I'm not sure the statement just made (by Steve) is an argument in favor of this change. I.e. "The problem is really hard" sometimes means that it is good to leave the plumbing to support solving the problem in your tools like rustc.

  • zwarich: In the systems programming world, people are much more willing to reinvent the wheel and write their own tools to do things. I'm not sure if [ ... ]

  • dherman: We should be careful about that. I think Rust has the opportunity to be the most usable systems language in the world, and I think it already is, and it keeps getting better. We have to be careful about setting the bar too low for ourselves. 'We are better than C++' is not good enough. [...] Think about 'on-ramps'. The easier it is to get started with your technology, the more people will use your technology. [...] If we can do better, we should do better.

  • zwarich: To extend the metaphor beyond what it should be, what if I'm in a vehicle that can't drive on the road we're building? Am I going to use cargo packages for my kernel modules?

  • dherman: We should! [...]

  • pcwalton: Primarily this is moving versioning out of rustc to the greatest extent possible, and I think that makes it [...]. rustc doesn't force you into a particular regime, which I think makes a lot of sense.

  • acrichto: The purpose of this RFC is to enable the usecases of cargo which aren't possible today. We can bolt crate_id on to the side of that. We don't need to remove that, but [...] seemed necessary to [...]

  • brson: I think there's a risk here that we say "yeah this sounds great" but nobody is thinking enough about this problem.

  • steve: A big advantage of this is that to pull attributes out of a crate reliably you need to parse rust code. Instead you can just parse a toml file [ ... ].

  • pnkfelix: We solved that by having flags for rustc to print that information. I'm not arguing that a config file is a better way to solve the problem, but I just want to be clear that a separate config file is not necessary to solve it.

  • steve: I was just trying to help you understand where people were coming from. [ ... ]

  • pnkfelix: From what acrichto said, it sounds like one can extract the info one wants via other means, if necessary for one's idiosyncratic setup. I'm not really going to object to this.

  • acrichto: As Steve was saying, this is departing from the style where all of your configuration goes in one file. [...] If you want to do it manually you can pass a huge list of command line arguments to rustc, though make would probably be doing it for you.

  • brson: let's go ahead. any objections? [none] Is this ready to go?

  • acrichto: yes.