Seeing this development on FFI makes me very happy. So it’s starting to look like we have agreement to add some form of FFI unions into the language? Under what conditions would the team consider a patch?
@sorear a design would need to be proposed and accepted as an RFC.
Before trying that, it may help to work out what to even propose in a different thread here.
Plugging my pre-RFC on size and alignment syntax for #[cfg(...)]. Should be submitted as a proper RFC soon.
I’d much rather my unsafe enum RFC as a way of dealing with unions.
What does redflag on aster mean? I was intersted in using it, but red flag sounds… ominous.
How many subcommands do we want for Cargo? Should this be a first-class thing?
Were any opinions voiced in answer to this question?
re cargo check - I want to see this, I think it's another arrow in the reply to our long compile-times complaint, so I'd like it to be first class in Cargo.
To answer the general question, I think we should expect Cargo to expand the number of sub-commands offered - it's the best way to ensure we have an easy to-use system of core tools. A Rust new-comer should just be able to download Cargo and have access to the standard suite of tools. They shouldn't have to follow a recipe on a web page to download a bunch of stuff and run a bunch of commands in order to get a standard environment - that is the C/C++ world which we are trying to get away from.
The downside is that this means we need to document better, and --help probably has to tier the sub-commands rather than just give a list, but I believe this is a solvable problem.
red flag on aster (wycats)
details please! Can we discuss this at the lang team meeting, whatever it is?
- cargo check (wycats)
- patterns (nmatsakis) How to handle pattern matching on constants - #16 by ahmedcharles
- std::time (wycats) Improvements to the Time APIs by wycats · Pull Request #1288 · rust-lang/rfcs · GitHub
- ffi complaint
- red flag on aster (wycats)
I'd like to remind the core team that we have sub-teams where some of these might be better (or at least primarily) discussed
The prevailing sentiment was that it's ok to have quite a few subcommands so long as any one particular person only needed to remember a handful. In that sense it didn't seem too bad to add more subcommands.
Also yeah our feeling was that we'd want to include cargo check as a first-class subcommand, just wanted to see how it worked in the wild by having it externally first!
I believe that's actually the intention of most of these topics, to just talk about them in a preliminary fashion ahead of time before bringing them up at subteam meetings. For example I'm sure we'll have quite the discussion about std::time in the libs meeting today when we get around to it!
Can I second the question about aster? We’re using in in Servo and it’d be great to know if it’s about to be yoinked from crates.io or something.
[quote=“alexcrichton, post:8, topic:2864”]
Also yeah our feeling was that we’d want to include cargo check as a first-class subcommand, just wanted to see how it worked in the wild by having it externally first!
[/quote]FWIW cargo check has been out there for a while.
This was @wycats raising the point that the Servo team is very familiar with: crates like Aster that are tied very closely to the compiler internals introduce a highly unstable sub-ecosystem that has to track specific nightlies, etc. It was a brief point raised as part of a discussion of allowing more experimentation via unstable features for things like FFI improvement.
Some of the point of the core team meeting is to broadcast information about particular contentious or important discussions from the subteams, to make sure that the full team is aware and to draw out cross-cutting concerns.
Remember, not every core team member attends every subteam meeting. But in trying to look out for global considerations and directions, it's important to bring these issues to the attention of the full team.
Technical discussion in the core team neither precludes nor supersedes technical discussion in subteams, and the RFC process is almost entirely run by the subteams. As @alexcrichton said, most of these issues will also be discussed in subteam meetings. And as always, all salient points that factor into team decisions should be argued publicly prior to a decision being issued.
Yep, I noticed that pretty quickly after the meeting and let everybody know. There's also cargo-watch. The Rust community is awesome 
@alexcrichton, @aturon thanks for the replies! Glad to hear we're in agreement about Cargo check. Thanks for clearing up the ASTer thing.
Some of the point of the core team meeting is to broadcast information about particular contentious or important discussions from the subteams
I get worried when I see things discussed which have not been brought up at the sub-teams or in public (which is 3/5 from the agenda this week). I guess it's ok if the preliminary discussion is happening here and then moving elsewhere, although it's not a pattern I would have expected.
To give another example of this, I recently was like "Hey, I've seen a lot of people asking about benchmark tests. Is the libs team talking about stabilizing this any time soon?" I'm not actually in the libs team meeting, so I can't bring it up there, so it has to start on the core team. Or at least, it's an easy time to raise the question.
The libs team is pretty active in #rust-libs, please don't hesitate to ping us with this sort of thing!
Yeah, that’s totally doable. In this case, we had ten minutes left at the end of the meeting, anyone have anything on their mind? So I mentioned it.
I guess just what I mean is that it’s not like decisions of any kind are being made here, it’s just cross-talk.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.