[rust-dev] Trait container return types
Hi everyone, I'm doing a bit of Rust coding and I'm trying to build a
library to manage some common business object behavior.
trait FieldT {
fn name() - ~str;
fn get_validators() - ~[ValidatorT];
fn get(self) - T;
fn is_valid(self) - bool;
}
trait Model {
fn get_fields(self) - ~[@Field];
fn validate(self) - OptionHashMap~str, ~[FieldError] {
}
The code fails with the following compiler error:
models.rs:80:35: 80:40 error: wrong number of type arguments: expected 1
but found 0
models.rs:80 fn get_fields(self) - ~[@Field];
The reason for the get_fields() method is to return a list of heterogenous
trait-upcasted objects, and for each of them I'd be invoking the is_valid()
method.
I would understand that the compiler may not understand the notion of trait
return types (which would make sense) but I'd be interested to know whether
this is a bug or a design limitation, and in the second case, whether
there's a sensible alternative.
Thanks
--
Andrés Osinski
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Trait container return types
The problem there is that `@Field` is not a type, because you haven't
specified the value for the generic constraint T. That is, the
pertinent trait object would be something like `@Fieldint`. It's not
possible to have a field without the type being specified; that is,
`get_fields()` can only be designed to return fields of one type
(think of it this way—what will the type checker think of the value of
`model.get_fields()[0].get()`? It's got to be exactly one type, but
it's not possible to infer it).
You'd need to deal with something like std::any::Any to achieve what
it looks likely that you're trying to do. Because I wouldn't encourage
designing something in that way as a starting point, I won't just now
give you code covering how you would implement such a thing; see if
it's possible for you to design it in such a way that this constraint
doesn't cause you trouble. Using enums instead of traits is one way
that can often—though certainly not always—get around this problem.
One final note—avoid using @-boxes if possible; is it possible for you
to give owned pointers or references?
On Sun, Dec 15, 2013 at 7:24 PM, Andres Osinski
andres.osin...@gmail.com wrote:
Hi everyone, I'm doing a bit of Rust coding and I'm trying to build a
library to manage some common business object behavior.
trait FieldT {
fn name() - ~str;
fn get_validators() - ~[ValidatorT];
fn get(self) - T;
fn is_valid(self) - bool;
}
trait Model {
fn get_fields(self) - ~[@Field];
fn validate(self) - OptionHashMap~str, ~[FieldError] {
}
The code fails with the following compiler error:
models.rs:80:35: 80:40 error: wrong number of type arguments: expected 1 but
found 0
models.rs:80 fn get_fields(self) - ~[@Field];
The reason for the get_fields() method is to return a list of heterogenous
trait-upcasted objects, and for each of them I'd be invoking the is_valid()
method.
I would understand that the compiler may not understand the notion of trait
return types (which would make sense) but I'd be interested to know whether
this is a bug or a design limitation, and in the second case, whether
there's a sensible alternative.
Thanks
--
Andrés Osinski
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Trait container return types
I'm on a phone so I haven't tested this, but I'd suggest removing the T
parameter of Field and replacing uses of T with Self. In case you don't
already know, Self is a implicit type parameter representing the type of
self, i.e. the type you impl the trait for. Would that work for your use
case?
On Dec 15, 2013 2:40 AM, Andres Osinski andres.osin...@gmail.com wrote:
I have not gotten around to examining the ownership issues of @-boxes -
I've used them because they're mentioned as the only way to do runtime
polymorphism - but I will definitely be looking at the Any type.
The essential point is that, for a set of FieldT containers, I want to
invoke a method whose signature does not have generic type parameters,
name the is_valid() method which would return a bool.
The thing is, the specialization for Field is something that I want to
leave open to the user, so an Enum solution or any solution which places a
constraint on T is not good for my use case. I'm open to doing whatever
unsafe manipulations would be necessary, but unfortunately there's not that
much code that's been written to go around to get an example.
On Sun, Dec 15, 2013 at 7:24 AM, Chris Morgan m...@chrismorgan.info wrote:
The problem there is that `@Field` is not a type, because you haven't
specified the value for the generic constraint T. That is, the
pertinent trait object would be something like `@Fieldint`. It's not
possible to have a field without the type being specified; that is,
`get_fields()` can only be designed to return fields of one type
(think of it this way—what will the type checker think of the value of
`model.get_fields()[0].get()`? It's got to be exactly one type, but
it's not possible to infer it).
You'd need to deal with something like std::any::Any to achieve what
it looks likely that you're trying to do. Because I wouldn't encourage
designing something in that way as a starting point, I won't just now
give you code covering how you would implement such a thing; see if
it's possible for you to design it in such a way that this constraint
doesn't cause you trouble. Using enums instead of traits is one way
that can often—though certainly not always—get around this problem.
One final note—avoid using @-boxes if possible; is it possible for you
to give owned pointers or references?
On Sun, Dec 15, 2013 at 7:24 PM, Andres Osinski
andres.osin...@gmail.com wrote:
Hi everyone, I'm doing a bit of Rust coding and I'm trying to build a
library to manage some common business object behavior.
trait FieldT {
fn name() - ~str;
fn get_validators() - ~[ValidatorT];
fn get(self) - T;
fn is_valid(self) - bool;
}
trait Model {
fn get_fields(self) - ~[@Field];
fn validate(self) - OptionHashMap~str, ~[FieldError] {
}
The code fails with the following compiler error:
models.rs:80:35: 80:40 error: wrong number of type arguments: expected
1 but
found 0
models.rs:80 fn get_fields(self) - ~[@Field];
The reason for the get_fields() method is to return a list of
heterogenous
trait-upcasted objects, and for each of them I'd be invoking the
is_valid()
method.
I would understand that the compiler may not understand the notion of
trait
return types (which would make sense) but I'd be interested to know
whether
this is a bug or a design limitation, and in the second case, whether
there's a sensible alternative.
Thanks
--
Andrés Osinski
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Andrés Osinski
http://www.andresosinski.com.ar/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Trait container return types
I'll have to consider it. To be honest this is my first endeavor in
attempting to capture classic OO business object-y rules using Rust-style
traits, and evidently I have some gaps in my knowledge and how to design
around those constraints.
On Sun, Dec 15, 2013 at 7:52 AM, Eric Reed ecr...@cs.washington.edu wrote:
I'm on a phone so I haven't tested this, but I'd suggest removing the T
parameter of Field and replacing uses of T with Self. In case you don't
already know, Self is a implicit type parameter representing the type of
self, i.e. the type you impl the trait for. Would that work for your use
case?
On Dec 15, 2013 2:40 AM, Andres Osinski andres.osin...@gmail.com
wrote:
I have not gotten around to examining the ownership issues of @-boxes -
I've used them because they're mentioned as the only way to do runtime
polymorphism - but I will definitely be looking at the Any type.
The essential point is that, for a set of FieldT containers, I want to
invoke a method whose signature does not have generic type parameters,
name the is_valid() method which would return a bool.
The thing is, the specialization for Field is something that I want to
leave open to the user, so an Enum solution or any solution which places a
constraint on T is not good for my use case. I'm open to doing whatever
unsafe manipulations would be necessary, but unfortunately there's not that
much code that's been written to go around to get an example.
On Sun, Dec 15, 2013 at 7:24 AM, Chris Morgan m...@chrismorgan.infowrote:
The problem there is that `@Field` is not a type, because you haven't
specified the value for the generic constraint T. That is, the
pertinent trait object would be something like `@Fieldint`. It's not
possible to have a field without the type being specified; that is,
`get_fields()` can only be designed to return fields of one type
(think of it this way—what will the type checker think of the value of
`model.get_fields()[0].get()`? It's got to be exactly one type, but
it's not possible to infer it).
You'd need to deal with something like std::any::Any to achieve what
it looks likely that you're trying to do. Because I wouldn't encourage
designing something in that way as a starting point, I won't just now
give you code covering how you would implement such a thing; see if
it's possible for you to design it in such a way that this constraint
doesn't cause you trouble. Using enums instead of traits is one way
that can often—though certainly not always—get around this problem.
One final note—avoid using @-boxes if possible; is it possible for you
to give owned pointers or references?
On Sun, Dec 15, 2013 at 7:24 PM, Andres Osinski
andres.osin...@gmail.com wrote:
Hi everyone, I'm doing a bit of Rust coding and I'm trying to build a
library to manage some common business object behavior.
trait FieldT {
fn name() - ~str;
fn get_validators() - ~[ValidatorT];
fn get(self) - T;
fn is_valid(self) - bool;
}
trait Model {
fn get_fields(self) - ~[@Field];
fn validate(self) - OptionHashMap~str, ~[FieldError] {
}
The code fails with the following compiler error:
models.rs:80:35: 80:40 error: wrong number of type arguments:
expected 1 but
found 0
models.rs:80 fn get_fields(self) - ~[@Field];
The reason for the get_fields() method is to return a list of
heterogenous
trait-upcasted objects, and for each of them I'd be invoking the
is_valid()
method.
I would understand that the compiler may not understand the notion of
trait
return types (which would make sense) but I'd be interested to know
whether
this is a bug or a design limitation, and in the second case, whether
there's a sensible alternative.
Thanks
--
Andrés Osinski
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Andrés Osinski
http://www.andresosinski.com.ar/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Andrés Osinski
http://www.andresosinski.com.ar/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Trait container return types
Can you have the definition be: fn get_fieldsT(self) - ~[@FieldT];?
--
Ziad
On Sun, Dec 15, 2013 at 3:13 AM, Andres Osinski andres.osin...@gmail.comwrote:
I'll have to consider it. To be honest this is my first endeavor in
attempting to capture classic OO business object-y rules using Rust-style
traits, and evidently I have some gaps in my knowledge and how to design
around those constraints.
On Sun, Dec 15, 2013 at 7:52 AM, Eric Reed ecr...@cs.washington.eduwrote:
I'm on a phone so I haven't tested this, but I'd suggest removing the T
parameter of Field and replacing uses of T with Self. In case you don't
already know, Self is a implicit type parameter representing the type of
self, i.e. the type you impl the trait for. Would that work for your use
case?
On Dec 15, 2013 2:40 AM, Andres Osinski andres.osin...@gmail.com
wrote:
I have not gotten around to examining the ownership issues of @-boxes -
I've used them because they're mentioned as the only way to do runtime
polymorphism - but I will definitely be looking at the Any type.
The essential point is that, for a set of FieldT containers, I want to
invoke a method whose signature does not have generic type parameters,
name the is_valid() method which would return a bool.
The thing is, the specialization for Field is something that I want to
leave open to the user, so an Enum solution or any solution which places a
constraint on T is not good for my use case. I'm open to doing whatever
unsafe manipulations would be necessary, but unfortunately there's not that
much code that's been written to go around to get an example.
On Sun, Dec 15, 2013 at 7:24 AM, Chris Morgan m...@chrismorgan.infowrote:
The problem there is that `@Field` is not a type, because you haven't
specified the value for the generic constraint T. That is, the
pertinent trait object would be something like `@Fieldint`. It's not
possible to have a field without the type being specified; that is,
`get_fields()` can only be designed to return fields of one type
(think of it this way—what will the type checker think of the value of
`model.get_fields()[0].get()`? It's got to be exactly one type, but
it's not possible to infer it).
You'd need to deal with something like std::any::Any to achieve what
it looks likely that you're trying to do. Because I wouldn't encourage
designing something in that way as a starting point, I won't just now
give you code covering how you would implement such a thing; see if
it's possible for you to design it in such a way that this constraint
doesn't cause you trouble. Using enums instead of traits is one way
that can often—though certainly not always—get around this problem.
One final note—avoid using @-boxes if possible; is it possible for you
to give owned pointers or references?
On Sun, Dec 15, 2013 at 7:24 PM, Andres Osinski
andres.osin...@gmail.com wrote:
Hi everyone, I'm doing a bit of Rust coding and I'm trying to build a
library to manage some common business object behavior.
trait FieldT {
fn name() - ~str;
fn get_validators() - ~[ValidatorT];
fn get(self) - T;
fn is_valid(self) - bool;
}
trait Model {
fn get_fields(self) - ~[@Field];
fn validate(self) - OptionHashMap~str, ~[FieldError] {
}
The code fails with the following compiler error:
models.rs:80:35: 80:40 error: wrong number of type arguments:
expected 1 but
found 0
models.rs:80 fn get_fields(self) - ~[@Field];
The reason for the get_fields() method is to return a list of
heterogenous
trait-upcasted objects, and for each of them I'd be invoking the
is_valid()
method.
I would understand that the compiler may not understand the notion of
trait
return types (which would make sense) but I'd be interested to know
whether
this is a bug or a design limitation, and in the second case, whether
there's a sensible alternative.
Thanks
--
Andrés Osinski
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Andrés Osinski
http://www.andresosinski.com.ar/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Andrés Osinski
http://www.andresosinski.com.ar/
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] IRC moderation due to attacks
On 15 Dec 2013, at 1:39 am, Jack Moffitt j...@metajack.im wrote: Some botnet is picking on #rust. Until the situation is resolved[1] or the botnet gives up, we've been turning on moderation in the #rust IRC room. This means that you won't be able to join #rust or talk in the channel unless you have registered with NickServ[2]. Right now the attack seems focused on #rust, but if the others channels start getting attacked as well we will have to turn on moderation there too. It would be useful if someone who has some free time could update the IRC page on the wiki to suggest people register their nicks and point them to the instructions below. You might also mention that moderation is employed from time to time to prevent spam bot attacks and that will prevent unregistered participants from joining and/or talking. We apologize for the inconvenience, and we'll hopefully be able to go back to our previous, unmoderated setup soon. jack. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=950187 [2] https://wiki.mozilla.org/IRC#Register_your_nickname ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev I was just hit by a bot spamming /querys on me using random nicks. Can’t connect to #rust. :( ~Brendan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] [whoami] crate, package and module confused me!
Rust compiler compiles crates, rustpkg manages packages. When develope a library for rust, I write these code in lib.rs: ``` #[pkgid = whoami]; #[crate_type = lib]; ``` Note, I set its package id, and set its crate type, and it is compiled to an .so library. Now please tell me, what it is? A package? A crate? or just a library? If it's a package, why I set its crate type? If it's a crate, why I set its package id? Confusing. And when use it (whoami), I must write the code: ``` extern mod whoami; ``` Now was it transmuted to a module?? If it's a module, why I haven't set its module id and module type? If it's not a module, why not use `extern package whoami` or `extern crate whoami` here? Full of confusion. Can you please tell me WHAT it really is? Thank you. ~~ The following is my answer and my solution: We remove crate everywhere. And the answer is obvious: it is a package. Package is a compile unit, it contains a root module (with the same name as pkgid), and module contains sub-modules. A package may be compiled to dynamic library, static library or executable program. package is a new keyword. When define a package, we first write one of these lines: ``` package newpkg; /// pkgid is newpkg, compile to dynamic library (.so) package main; /// pkgid main means compile to executable program (.exe) static package newpkg; /// pkgid is newpkg, compile to static library ``` It replaced the #[pkgid] and #[crate_type], the doc-comments replaced the #[desc]. When declare using the package, we write code: ``` extern package newpkg; // or … extern package newpkg = http://github.com/liigo/rust-newpkg#newpkg:1.0;; ``` The `extern package newpkg;` should be optional, because, when we write: ``` use newpkg::a::b; ``` … rust compiler always knows it's using extern package `newpkg`. (If name conflicts with local module, compiler should emit an error.) Liigo, 2013-12-15. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] IRC moderation due to attacks
And we're having a large amount of bot-spam in the main channel right now. (Although, it did get the channel up to 1000 people at one point, so it's not all bad.) Huon On 15/12/13 23:41, Brendan Zabarauskas wrote: On 15 Dec 2013, at 1:39 am, Jack Moffitt j...@metajack.im wrote: Some botnet is picking on #rust. Until the situation is resolved[1] or the botnet gives up, we've been turning on moderation in the #rust IRC room. This means that you won't be able to join #rust or talk in the channel unless you have registered with NickServ[2]. Right now the attack seems focused on #rust, but if the others channels start getting attacked as well we will have to turn on moderation there too. It would be useful if someone who has some free time could update the IRC page on the wiki to suggest people register their nicks and point them to the instructions below. You might also mention that moderation is employed from time to time to prevent spam bot attacks and that will prevent unregistered participants from joining and/or talking. We apologize for the inconvenience, and we'll hopefully be able to go back to our previous, unmoderated setup soon. jack. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=950187 [2] https://wiki.mozilla.org/IRC#Register_your_nickname ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev I was just hit by a bot spamming /querys on me using random nicks. Can’t connect to #rust. :( ~Brendan ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [whoami] crate, package and module confused me!
I prefere keeping crate and package, turn crate_type to package_typa, and change mod keyword to crate. But I don't know what rust devevelopers think #[pkgid = whoami]; #[package_type = lib]; ... extern crate whoami - Gaetan 2013/12/15 Liigo Zhuang com.li...@gmail.com Rust compiler compiles crates, rustpkg manages packages. When develope a library for rust, I write these code in lib.rs: ``` #[pkgid = whoami]; #[crate_type = lib]; ``` Note, I set its package id, and set its crate type, and it is compiled to an .so library. Now please tell me, what it is? A package? A crate? or just a library? If it's a package, why I set its crate type? If it's a crate, why I set its package id? Confusing. And when use it (whoami), I must write the code: ``` extern mod whoami; ``` Now was it transmuted to a module?? If it's a module, why I haven't set its module id and module type? If it's not a module, why not use `extern package whoami` or `extern crate whoami` here? Full of confusion. Can you please tell me WHAT it really is? Thank you. ~~ The following is my answer and my solution: We remove crate everywhere. And the answer is obvious: it is a package. Package is a compile unit, it contains a root module (with the same name as pkgid), and module contains sub-modules. A package may be compiled to dynamic library, static library or executable program. package is a new keyword. When define a package, we first write one of these lines: ``` package newpkg; /// pkgid is newpkg, compile to dynamic library (.so) package main; /// pkgid main means compile to executable program (.exe) static package newpkg; /// pkgid is newpkg, compile to static library ``` It replaced the #[pkgid] and #[crate_type], the doc-comments replaced the #[desc]. When declare using the package, we write code: ``` extern package newpkg; // or … extern package newpkg = http://github.com/liigo/rust-newpkg#newpkg:1.0;; ``` The `extern package newpkg;` should be optional, because, when we write: ``` use newpkg::a::b; ``` … rust compiler always knows it's using extern package `newpkg`. (If name conflicts with local module, compiler should emit an error.) Liigo, 2013-12-15. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [whoami] crate, package and module confused me!
On 12/15/2013 07:52 AM, Liigo Zhuang wrote:
Rust compiler compiles crates, rustpkg manages packages.
When develope a library for rust, I write these code in lib.rs
http://lib.rs:
```
#[pkgid = whoami];
#[crate_type = lib];
```
Note, I set its package id, and set its crate type, and it is
compiled to an .so library. Now please tell me, what it is? A package?
A crate? or just a library? If it's a package, why I set its crate type?
If it's a crate, why I set its package id? Confusing.
I agree that 'pkgid' is a really unfortunate name that stems from the
confusion of whether or not a package is allowed to contain multiple
crates. I think it should, but it feels like I'm in a minority. 'pkgid'
is used to generate the crate output name, at least for libraries, (i.e.
libname-hash-version.so). Frankly, I liked the old link metadata
idea better where you specified the Author, Version and output name
separately, and it was not conflated with the rustpkg idea. I believe
the movement to #[pkgid] was driven by the desire for external tools to
be able to compute the hash (e.g. see
http://metajack.im/2013/12/12/building-rust-code--using-make/)... but I
think that's a mistake. I really don't think this is a solution:
RUST_CRATE_PKGID = $(shell sed -ne 's/^#[ *pkgid *= *(.*) *];$$/\1/p'
$(firstword $(1)))
RUST_CRATE_HASH = $(shell printf $(strip $(1)) | shasum -a 256 | sed -ne
's/^(.{8}).*$$/\1/p')
_rust_crate_pkgid = $$(call RUST_CRATE_PKGID, $$(_rust_crate_lib))
_rust_crate_hash = $$(call RUST_CRATE_HASH, $$(_rust_crate_pkgid))
I'd rather just do:
RUST_CRATE_HASH = $(shell rustc --get-crate-hash $1)
_rust_crate_hash = $$(call RUST_CRATE_HASH, $$(_rust_crate_lib))
Personally, I'd remove the notion of a package id from the language, and
leave it entirely up to the external package management tool to deal with.
That'd mean the removal of the unfortunate `extern mod foo = pkgid;`
syntax which conflates crates and packages (it could be replaced with
`#[pkgid=pkgid] extern mod foo;` if source annotation of external
dependencies is really desired. It'd have to have different semantics in
order not to repeat the confusion.).
And when use it (whoami), I must write the code:
```
extern mod whoami;
```
Now was it transmuted to a module?? If it's a module, why I haven't
set its module id and module type? If it's not a module, why not use
`extern package whoami` or `extern crate whoami` here? Full of confusion.
Can you please tell me WHAT it really is? Thank you.
For what it is worth, extern mod is slated to be changed to be
crate, I think: https://github.com/mozilla/rust/issues/9880 .
-SL
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [whoami] crate, package and module confused me!
I agree this is a mess and we need to resolve this quickly. On 12/15/2013 04:52 AM, Liigo Zhuang wrote: Rust compiler compiles crates, rustpkg manages packages. When develope a library for rust, I write these code in lib.rs http://lib.rs: ``` #[pkgid = whoami]; #[crate_type = lib]; ``` Note, I set its package id, and set its crate type, and it is compiled to an .so library. Now please tell me, what it is? A package? A crate? or just a library? If it's a package, why I set its crate type? If it's a crate, why I set its package id? Confusing. And when use it (whoami), I must write the code: ``` extern mod whoami; ``` Now was it transmuted to a module?? If it's a module, why I haven't set its module id and module type? If it's not a module, why not use `extern package whoami` or `extern crate whoami` here? Full of confusion. Can you please tell me WHAT it really is? Thank you. ~~ The following is my answer and my solution: We remove crate everywhere. And the answer is obvious: it is a package. My feeling is that it is a crate, since that's the name we've historically used. There's already been agreement to remove extern mod in favor of crate. Package is a compile unit, it contains a root module (with the same name as pkgid), and module contains sub-modules. A package may be compiled to dynamic library, static library or executable program. package is a new keyword. When define a package, we first write one of these lines: ``` package newpkg; /// pkgid is newpkg, compile to dynamic library (.so) package main; /// pkgid main means compile to executable program (.exe) static package newpkg; /// pkgid is newpkg, compile to static library ``` It replaced the #[pkgid] and #[crate_type], the doc-comments replaced the #[desc]. When declare using the package, we write code: ``` extern package newpkg; // or ... extern package newpkg = http://github.com/liigo/rust-newpkg#newpkg:1.0;; ``` The `extern package newpkg;` should be optional, because, when we write: ``` use newpkg::a::b; ``` ... rust compiler always knows it's using extern package `newpkg`. (If name conflicts with local module, compiler should emit an error.) Liigo, 2013-12-15. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
