Re: [rust-dev] Alternative proposal for `use crate`

On 12/17/2013 09:40 PM, Jack Moffitt wrote: `extern use foo` has the some of the same drawbacks as `use crate foo`. The `use` might lead people to think you can do `use crate foo::bar`. The fact that there wasn't a whole lot of love for any particular options suggests maybe we should wait for mor

Re: [rust-dev] [whoami] "crate", "package" and "module" confused me!

`use crate foo; ` looks good to me. i always think it should be optional. rustc can deduce which crate will be used, from use mods lines, in most situations. 2013/12/18 Brian Anderson > We discussed this some in the meeting today: > https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-12-1

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow wrote: > Hi, > > > Am 09.12.2013 um 16:53 schrieb Damien Radtke : > >> I have no idea if it would be feasible in the standard library, but wouldn't >> the ideal solution be having one function (e.g. from_utf8()) that could >> return two possible

Re: [rust-dev] [whoami] "crate", "package" and "module" confused me!

We discussed this some in the meeting today: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-12-17 On 12/16/2013 06:41 PM, Liigo Zhuang wrote: 2013/12/16 Brian Anderson > My feeling is that it is a crate, since that's the name we've historically

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

Hi, Am 09.12.2013 um 16:53 schrieb Damien Radtke : > I have no idea if it would be feasible in the standard library, but wouldn't > the ideal solution be having one function (e.g. from_utf8()) that could > return two possible values, a bare result and an Option? Letting the compiler > decide

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

Hi, Am 17.12.2013 um 20:10 schrieb Corey Richardson : > On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow > wrote: >> Hi, >> >> >> Am 09.12.2013 um 16:53 schrieb Damien Radtke : >> >>> I have no idea if it would be feasible in the standard library, but >>> wouldn't the ideal solution be havi

Re: [rust-dev] Alternative proposal for `use crate`

`extern use foo` has the some of the same drawbacks as `use crate foo`. The `use` might lead people to think you can do `use crate foo::bar`. The fact that there wasn't a whole lot of love for any particular options suggests maybe we should wait for more ideas. It occurs to me now that `extern foo

Re: [rust-dev] Alternative proposal for `use crate`

After chatting with Alex Crichton on IRC, it turns out `use crate` was actually rejected. It just wasn't captured properly in the notes. Apparently the current leading proposal is `extern crate foo`. This still has the problem of defining a new limited-scope keyword, but it's better than `use c

[rust-dev] Alternative proposal for `use crate`

In today's meeting[1], it appears as though `extern mod foo` may become `use crate foo`. I have a minor worry about this, which is reserving yet another keyword for a very limited usage. My general feeling is we shouldn't be adding keywords unnecessarily, especially if their scope is extremely l

Re: [rust-dev] Let’s avoid having both foo() and foo_opt()

On Dec 17, 2013, at 11:37 AM, Stefan Plantikow wrote: > Hi, > > Am 17.12.2013 um 20:10 schrieb Corey Richardson : > >> On Tue, Dec 17, 2013 at 2:06 PM, Stefan Plantikow >> wrote: >>> Hi, >>> >>> >>> Am 09.12.2013 um 16:53 schrieb Damien Radtke : >>> I have no idea if it would be feasi