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

Latest commit

 

History

History
196 lines (167 loc) · 15.6 KB

2014-07-15.md

File metadata and controls

196 lines (167 loc) · 15.6 KB
Raw

Agenda 7/15/2014

Attending

Luqman, cmr, jclements, brson, steve, acrichto, aturon, zwarich, nrc, jack, felix, azita, stuart, huon

Status

  • brson: gcc bundling, timer API's, API review, possibly working on research blog post
  • aturon: RFCs! several for error/result/conventions; circular concurrent buffer; rust-book
  • nrc: DST deep coercions, review fixes, Vec Index impl, preparing a bunch of talks and tutorials
  • acrichto: cargo cross compile, acceptor::{clone, close_accept}, cargo website
  • pnkfelix: non-zeroing drop (flow analysis)

Action Items

RFC PR 16 (attrs on statements/blocks)

  • felix: The text of the RFC was somewhat more generalized than the title suggests, most expressions would allow attributes. The corner case huon was refering to was if expressions, and whether the attribute applies to the entire if expression of the else parts and the else ifs and so on. I asked him if we really need to support that usecase, and if we can instead just wrap those parts in a block and put the attribute on that. He was receptive and updated the RFC to not allow them on if expressions.
  • brson: To be clear, this allows attributes on almost every expression, with a special case for if?
  • felix: That's right. I don't think there are any other exceptions. Some people did say "Man, in C or C++ it's really hard to look through a nested series of #ifdefs", but he pointed out the RFC is specifically about attributes, and whether #[cfg] applies to expressions is not part of the RFC, and we can decide it separately. We can say #[cfg] on an expression is an error, which I think is a pretty sensible thing to do.
  • jclements: My understanding is that attributes are a different syntax for macros.
  • acrichto: I see it differently, e.g. #[cold] on branches.
  • felix: another example is in the RFC: an adhoc pseudo-effect system for unsafe (e.g. limit to FFI invocations).
  • jclements: For instance, we scan for cfg blocks before and after expansion, obvious thing is to do them at the same time...
  • felix: Ah, you're talking about the interaction between expansion and attributes.
  • brson: This RFC has gone through several rounds of discussion, and I think ... [merge it] ... does anyone disagree with that?
  • acrichto: Are we certain there aren't [grammatical] ambiguities?
  • cmr: I'm pretty confident there are no ambiguities.
  • jclements: If I see an attribute, it could be an expression or a statement, how do we handle that?
  • cmr: Yes, we'd need to keep it around ... the only statement is let?
  • ...
  • brson: John, how do you feel about that?
  • jclements: Sounds awesome!
  • zwarich: ... should be LL if you do it that way.

RFC PR 131 - flexible target specs

  • cmr: older, no discussion. people writing kernel don't want stack size checking
  • cmr: other considerations like which linker to invoke per target
  • cmr: this allows extending targets by passing in a flag. rather than hardcoding configs for --target, also loads from file. RFC details what can be specced.
  • acrichto: this is updated a bit. need to read
  • brson: in favor of solving this problem somehow. haven't read details
  • cmr: open question: if you use --target foo, change the config and compile more crates, they will mismatch.
  • brson: obvious solution is yet another hash, right?
  • cmr: alex expressed not wanting to put more in metadata
  • acrichto: if you are customizing stuff then you are smart enough to do things correctly
  • cmr: failure mode is impenetrable
  • felix: are there config changes that you would want to link together?
  • cmr: interesting point
  • cmr: e.g. disabling stack size checking, you don't want them to interoperate
  • brson: can leave this question open
  • brson: other concerns about the technicals?
  • cmr: what config format? i'd like json
  • acrichto: find it odd we don't have config files.
  • brson: overlap here with old designs for merging config files (crate attrs)
  • cmr: could just make it a rust file
  • acrichto: llvm does target normalization. this would require people to create their own target triple. not sure how llvm will behave
  • brson: we may need our own normalization
  • cmr: this RFC explicitly calls for passing a specific triple to llvm that differs from the front-end triple
  • cmr: zwarich?
  • zwarch: there are subtleties, but i'm not up to speed. you do need to use the correct triples because llvm makes decisions based on it.

Integer inference fallback retrospective

  • brson: A couple of weeks ago we landed this. We expected it to have very little fallout, but that assumption turned out to be wrong. It affected a lot of code, but we pushed it through anyway. There's no major problem here, but this had a huge impact and we have to write specific integer types where we didn't think we'd need to. Any comments?
  • nrc: Can you give a specific example if where we didn't think it'd be needed but it is?
  • brson: I'll look for one.
  • acrichto: There are two pieces of this. The first PR had the expected fallout except perhaps in testcases. The second ones statistics was based on the first PRs statistics which didn't actually remove all of the fallback, it didn't look at tests, it was only looking at a small subset.
  • zwarich: There was also a suggestion to remove the float inference. It's weird to me because the first time you are writing code you don't necessarily know what type you want. You almost need to run a typechecker in your head to decide what type you should use.
  • steve: It's also hard for teaching, I don't know what to tell people, I've just been adding i after things.
  • zwarich: And I'm not sure the same justifications apply to float inference.
  • brson: Is that something we've done? It sounds unfamiliar to me.
  • cmr: I thought it was just a suggestion.
  • acrichto: We removed float inference with the others.
  • acrichto: Nick, [...]
  • nrc: I'm not asking where we do need to do it, but where we need to do it where we didn't think we'd need to.
  • zwarich: PR 15234

https://github.com/rust-lang/rust/pull/15234/files

  • acrichto: I feel this is a little bit like unboxed closures where these were all expected, it was just one of those things where a small modification on a very large base. Small percentage, large amount of code.
  • nrc: I think the same thing happened with the cross-borrowing removal. In actual code it was like 7 changes, but hundreds of testcases.
  • acrichto: That's true. Its arguable if tests are represenative of good Rust code, or of Rust code at all. I think it goes both ways.
  • brson: Anything else on this subject?
  • acrichto: I have never ascribed to anything besides an int. Every time I've added a hint, I haven't cared.
  • steve: I'd like guidance on what to tell people regarding annotations.
  • cmr: I think this is part of a larger problem where when you write a number, you don't always know what type you want until you have more information. You need to pick something, and I think people are going to pick i because that's short, and has a nice name, int. But maybe we should "default" to i32, or i64, or something else.
  • ...
  • steve: One example is a for loop with a range ,"Why do I need to annotate one or the other?"
  • brson: I think thinking about it is the key thing here. We've regressed ergonomically, and this is something to keep on a radar.
  • felix: With the for example, does that happen in real code?
  • cmr: Yes.
  • acrichto: I've written lots of range recently where I needed to add a type.
  • felix: I guess I've just been feeding in the type from something else.

RFC PR 108

  • nrc: This is a fairly minor change for the use module syntax. When you're giving a list of modules to import, you can use the self keyword to import the individual module itself as well as items from it. This stems from the pattern where you write use syntax::ast on one line and then import a bunch of stuff from it. Feedback is generally positive, some bikeshedding about what keyword to use. Seems like this would be very [...] to implement, and a decent win. Not sure if anyone rejects the idea on principle.
  • zwarich: I think whatever you put there, you should be able to use in a module path. Can I use self::..., or are we going to ...., not sure you could use self/mod, might be crazy ambiguities. Why should module paths be different in one part of the language than the other, for this?
  • jclements: I agree with that, the symmetry is nice.
  • nrc: That's true, but in this context module paths are different, they are absolute rather than relative.
  • brson: use statements also are only context where you can use curly braces
  • aturon: Further note, the RFC only allows you to use it when you are using braces.
  • cmr: That seems obvious, since otherwise you wouldn't need self.
  • acrichto: My concern is that it looks like you're importing the identifier self, but then never using that.
  • zwarich: Can you nest braces or is that another RFC?
  • brson: It has been proposed.
  • jclements: Possibly orthogonal, but I just spent about a week dealing with self not being a normal identifiers.
  • [in the weeds]
  • nrc: We could use a different keyword, we have like 30 to use.
  • brson: self is already on the doldrums, we might as well put all the nastiness in that one keyword.
  • [laughing]
  • brson: Anyone opposed to self?
  • jclements: [...]
  • [...]
  • brson: Can you explain the problem again? It's specifically about the word self?
  • jclements: It can be used as a binding, [...]
  • felix: We could use mod, and that's a character shorter!
  • [...]
  • brson: Keep in mind that we already use self in imports.
  • jclements: [grumbling]
  • brson: But seriously, do you think we'd be better off using something else than self here?
  • jclements: I'll stop complaining.
  • nrc: That's a good point and makes me somewhat less keen on self, since now it has two meanings in imports.
  • felix: There is an analogy here, its just following a path; self at the start is the root of the path, and otherwise, you're walking down the path until you find the module you want
  • nrc: That's not quite true: self at the beginning means relative lookup (relative to the current module); self not at the beginning means absolute lookup (relative to the crate root)
  • felix: You're right, my reasoning is bogus, we should use mod.
  • brson: It sounds like everyone is psyched about the word mod.
  • [sarcastic cheering]
  • brson: Can someone clean this up? All you need to do is change it to mod.
  • nrc: I'll do it.
use {foo, bar, baz}; // ok, even today
use {mod, bar, baz}; // bad, what identifier does `mod` bind?
  • acrichto: The first is allowed, but we should deny the second since there is no name for mod to refer to.
  • nrc: Who should I ping when I've done it?
  • brson: Me

RFC PR 101

  • nrc: Generalized pattern syntax for matching slices. A lot of feedback, but positive. Doesn't seem to be a cost to adding more complexity here?
  • cmr: I think we should hold off on doing anything about this until some of the other open questions on slice patterns get resolved.
  • brson: Patrick and I are somewhat gunshy about adding more complexity here, it's not clear that it's buying us a lot. Match is getting very complex, and we don't know we can implement the exhaustiveness check correctly.
  • zwarich: I refered to that in the bug, but I ... with the fixed size restriction, there's no problem implementing it. With an other issue in subslice borrowing that got closed before the review, Jakub, Gabor, and myself figured out how to do exhaustiveness checking, including what this RFC adds. There's a question if this is useful since you can't move out of this. What people really want is to move out of vectors, something like box patterns. So this isn't that useful.
  • brson: Can you explain what the fixed size restriction is?
  • zwarich: All of the patterns that he has are [x..3, y..4] saying you have 3 xs or 4ys and it expands to be basically the same thing as tuple matching, or if you had written the same thing multiple times, as opposed to [..xs, ..ys] where xs and ys could be arbitrary length.
  • brson: Any further comments?
  • nrc: One other option is that if we want to postpone doing this, it's not quite backwards compatible, but the only thing we'd need to do to make it backwards compatible is to make putting the .. before the identifier instead of after. Not sure if we just want to accept that part of the RFC.
  • brson: Last time that question came up, we said no because we don't want to do any of this stuff, but it keeps coming up, maybe we should future-proof it.
  • nrc: Does anyone feel strongly that we should do this now? Or that we should not do the future-proofing part of this now?
  • acrichto: I think it's sketchy to keep adding these features to match. Everyone I know is familiar with the code is saying "stop adding features, it's heinous".
  • brson: I'm pretty negative on this, and Patrick is vehemently against it. But the future proofing is low impact, and I'm not opposed to it.
  • acrichto: We could. I don't really like having change just to change.
  • brson: Sounds pretty lukewarm, let's just not do this right now.

RFC PR 113

  • nrc: Aaron, can you give us an update on this?
  • aturon: I worked with bjz on this earlier in the week. We want to propose a more conservative alternative. The plan is to close this RFC, I'm about to add 2 or 3 RFCs about error/option stuff that revises this.

RFC PR 116

  • nrc: Forbids name collision in imports by feature gating them. All the feedback was very positive. Patrick seems keen on doing this, I think it's a simplification?
  • acrichto: This has implications on the API of the stdlib, fmt::Result would need to be renamed. Nothing would ever be able to take those names. Just as a fact.
  • felix: The comments in the RFC say possibly allowing shadows just for things in the prelude.
  • cmr: I don't want to make the prelude more special.
  • nrc: I agree.
  • brson: That it simplifies resolve doesn't ring true to me, since we still need to support it.
  • nrc: I think the idea is that we remove it after a while.
  • aturon: ... my understanding is that those rules are because of shadowing, and we want to force you to import things in a certain order, and I've never particularly understood them. ...
  • cmr: ... extern crate ...
  • brson: Does the RFC address this?
  • aturon: Yes, names introduced by extern crate and use may never collide.
  • nrc: (starts talking, connection dies)
  • [details]
  • felix: Correct me if I'm wrong John, but racket has something where you can do a glob import except for certain names. But that'd be adding a new feature to support this RFC.
  • brson: I am going to suggest this is a big enough feature with enough open questions that we cannot take action on it immediately.

cmr: I was thinking last night about how Rust is perceived. in particular, Rust has a rich oral history, the project has been around for a number of years, a lot of people have worked on it, and it's not clear that people know this. There's a lot of knowledge trapped in the core peoples' heads. It would be nice to tease that out in some form. For Instance, the "this week in rust" ... a lot of people like the idea of a podcast. Perhaps we (i?) could interview core team members. brson: i agree in general. I think we should do something related to that. also, the podcast could illuminate some of the dark ideas that some people are not aware of. but! out of time!