Re: [rust-dev] Confusing way to declare a uint

2014-11-03 Thread Matthew McPherrin
You're not alone.  This was bikeshedded a while back, and I think the
decision was that 8uint felt too verbose for what is a common thing,
and that renaming uint to u was inappropriately short.

I think this topic isn't 100% closed yet, in particular renaming uint
to something like uintptr or usize or something has been brought up.
Github isn't loading for me right now, but I think there might have
been an open RFC in this area.

On Mon, Nov 3, 2014 at 12:19 PM, Jake Scott  wrote:
> I was trying to declare a uint using this:
> let a: uint = 0_uint;
>
> But the correct way to declare it is:
> let a: uint = 0u;
>
> Anyone else think that's not consistent?
>
>
>
>
> ___
> 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] Confusing way to declare a uint

2014-11-03 Thread Benjamin Herr
With the other numeric types, I'd assume. 0_i8, 0_f32 etc all work.

On Mon, 2014-11-03 at 15:25 -0500, Evan G wrote:
> Not consistent with what? The syntax for number literals is taken
> directly from C/C++, and is used by many other languages.
> 
> 
> On Mon, Nov 3, 2014 at 3:19 PM, Jake Scott  wrote:
> I was trying to declare a uint using this:
> let a: uint = 0_uint;
> 
> 
> 
> But the correct way to declare it is:
> let a: uint = 0u;
> 
> 
> 
> Anyone else think that's not consistent? 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Confusing way to declare a uint

2014-11-03 Thread Evan G
try `let i = 0i64` :D it just uses the platform to infer the width by
default. Because number literals show up very commonly throughout Rust
code, its important that we keep them short and unobtrusive by default
though, so its normally just recommended to use the short forum unless you
need a smaller/larger type for some reason.

more detail can be found in the rust reference:
http://doc.rust-lang.org/reference.html#number-literals

On Mon, Nov 3, 2014 at 3:37 PM, Jake Scott  wrote:

> I come from a C# background, so the literal syntax is all new to me. I
> know about type inference but I am being explicit to demonstrate what I
> think is a trap for young players :)
>
> let i: i32 = 0_i32; // uses 'i32' on both sides of the declaration
> let l: u64 = 0_u64; // uses 'u64' on both sides of the declaration
>
> let j: int = 0i; // uses 'int' and 'i' which is different on both sides of
> the declaration
>
>
>
>
>
>
>
>
> On Tue, Nov 4, 2014 at 9:27 AM, Evan G  wrote:
>
>> Also, because you have the type information in the variable, there's no
>> need to redundantly include it by making it an unsigned number literal—rust
>> can infer that information.
>>
>> On Mon, Nov 3, 2014 at 3:25 PM, Evan G  wrote:
>>
>>> Not consistent with what? The syntax for number literals is taken
>>> directly from C/C++, and is used by many other languages.
>>>
>>> On Mon, Nov 3, 2014 at 3:19 PM, Jake Scott  wrote:
>>>
 I was trying to declare a uint using this:
 let a: uint = 0_uint;

 But the correct way to declare it is:
 let a: uint = 0u;

 Anyone else think that's not consistent?




 ___
 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] Confusing way to declare a uint

2014-11-03 Thread Jake Scott
I come from a C# background, so the literal syntax is all new to me. I know
about type inference but I am being explicit to demonstrate what I think is
a trap for young players :)

let i: i32 = 0_i32; // uses 'i32' on both sides of the declaration
let l: u64 = 0_u64; // uses 'u64' on both sides of the declaration

let j: int = 0i; // uses 'int' and 'i' which is different on both sides of
the declaration








On Tue, Nov 4, 2014 at 9:27 AM, Evan G  wrote:

> Also, because you have the type information in the variable, there's no
> need to redundantly include it by making it an unsigned number literal—rust
> can infer that information.
>
> On Mon, Nov 3, 2014 at 3:25 PM, Evan G  wrote:
>
>> Not consistent with what? The syntax for number literals is taken
>> directly from C/C++, and is used by many other languages.
>>
>> On Mon, Nov 3, 2014 at 3:19 PM, Jake Scott  wrote:
>>
>>> I was trying to declare a uint using this:
>>> let a: uint = 0_uint;
>>>
>>> But the correct way to declare it is:
>>> let a: uint = 0u;
>>>
>>> Anyone else think that's not consistent?
>>>
>>>
>>>
>>>
>>> ___
>>> 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] Confusing way to declare a uint

2014-11-03 Thread Evan G
Also, because you have the type information in the variable, there's no
need to redundantly include it by making it an unsigned number literal—rust
can infer that information.

On Mon, Nov 3, 2014 at 3:25 PM, Evan G  wrote:

> Not consistent with what? The syntax for number literals is taken directly
> from C/C++, and is used by many other languages.
>
> On Mon, Nov 3, 2014 at 3:19 PM, Jake Scott  wrote:
>
>> I was trying to declare a uint using this:
>> let a: uint = 0_uint;
>>
>> But the correct way to declare it is:
>> let a: uint = 0u;
>>
>> Anyone else think that's not consistent?
>>
>>
>>
>>
>> ___
>> 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] Confusing way to declare a uint

2014-11-03 Thread Evan G
Not consistent with what? The syntax for number literals is taken directly
from C/C++, and is used by many other languages.

On Mon, Nov 3, 2014 at 3:19 PM, Jake Scott  wrote:

> I was trying to declare a uint using this:
> let a: uint = 0_uint;
>
> But the correct way to declare it is:
> let a: uint = 0u;
>
> Anyone else think that's not consistent?
>
>
>
>
> ___
> 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


[rust-dev] Confusing way to declare a uint

2014-11-03 Thread Jake Scott
I was trying to declare a uint using this:
let a: uint = 0_uint;

But the correct way to declare it is:
let a: uint = 0u;

Anyone else think that's not consistent?
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Using an external crate from a module

2014-11-03 Thread Ben Foppa
I don't know whether it's *discouraged*, but you're right that things get
confusing quickly. So far, keeping all the `mod`s and `extern crate`s in a
separate file (a la
https://github.com/bfops/playform/blob/339667691197ec02afd2fee55d080e541723b12e/src/playform.rs)
hasn't given me any issues, so I haven't had a reason not to default to
that.

On Sun, Nov 2, 2014 at 9:22 AM, David Henningsson  wrote:

> Hi,
>
> I'm wondering if "external crate" declarations from modules are
> discouraged in general? Because things seem to become a bit quirky, took me
> a while to grasp:
>
> First, "use" starts at the root whereas everything else starts at the
> current module. E g, imagine a "test_seri.rs" file which looks like this:
>
> extern crate serialize;
>
> fn test_json() {
> use self::serialize::json;
> let _:int = json::decode("").unwrap();
> }
>
> fn test_json2() {
> let _:int = serialize::json::decode("").unwrap();
> }
>
> So, since the "serialize" crate is inserted into the test_seri namespace,
> I have to do "use self::serialize::json" and not "use serialize::json" in
> the example above. But still I can call "serialize::json::decode" in the
> second example without using the entire path "self::serialize::json" (or
> test_seri::serialize::json). This is a bit inconsistent, but doable once
> you understand it.
>
> Second, in the case of the log crate, it looks like it can only be
> imported in the root crate, not in a module. For two reasons. Imagine a "
> test_log.rs" file looking like this:
>
> #![feature(phase)]
> #[phase(plugin, link)] extern crate log;
>
> fn test_log() {
> error!("Yo!");
> }
>
> The first is that "#![feature(phase)]" seems to be silently ignored when
> not in crate root. You'll get a somewhat confusing compiler error on the
> second row: "add #![feature(phase)] to the crate attributes to enable" -
> it's confusing until you get that you have added "#![feature(phase)]" to a
> module, not a crate.
>
> The second is that the log macros ("error!" etc) reference
> ::log::LogLocation, which assumes that the log is actually imported as
> ::log. Which it isn't in this case, it's test_log::log. Again a confusing
> compiler error "error: failed to resolve. Maybe a missing `extern crate
> log`?".
> (Side note: the macros are also broken if you do stuff such as 'extern
> crate "log" as foo'.)
>
> // David
> ___
> 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] Programmaticaly accessing compiler warnings

2014-11-03 Thread Nick Cameron
I filed https://github.com/rust-lang/rust/issues/18579. Please ping me (nrc
or @nick29581) if you have any implementation questions and/or for review.

Cheers, Nick

On Mon, Nov 3, 2014 at 7:28 PM, Anton Löfgren 
wrote:

> I'm interested as well. Is there an issue on GH tracking this?
>
> /Anton
>
> On November 2, 2014 11:38:13 PM CET, Manish Goregaokar <
> manishsm...@gmail.com> wrote:
>>
>> I'm interested, though rather busy right now (free after the second week
>> of November)
>>
>> -Manish Goregaokar
>>
>> On Mon, Nov 3, 2014 at 1:56 AM, Nick Cameron  wrote:
>>
>>> There currently isn't, but I'd like to add API for this as part of the
>>> rustc::middle::save module. If anyone is interested in implementing that,
>>> it shouldn't be too hard and I'd be happy to help out.
>>>
>>> Cheers, Nick
>>>
>>> On Sun, Nov 2, 2014 at 11:32 AM, Andreas Tolfsen 
>>> wrote:
>>>
 On Sat, Nov 1, 2014 at 3:08 PM, Vladimir Pouzanov 
 wrote:
 > Is there any way to access compiler warnings and errors other than
 parsing
 > stdout? I'd prefer a bit more structured approach.

 Most editors such will understand the output format from the compiler:

 /home/ato/Code/wires/src/response.rs:30:17: 30:20 warning: unused
 variable: `msg`, #[warn(unused_variables)] on by default

 In Emacs there are a number of built-in functions to deal with the
 output in the compilation mode buffer:

 https://www.gnu.org/software/emacs/manual/html_node/emacs/Compilation-Mode.html

 In vi you can type :cwindow to access the compile window.

 And in Acme you can simply right-click somefile.rs:42:12 to go to
 column 12 in line 42 in somefile.rs.

 So the output the compiler gives is machine readable, and there are
 many more tools that understand it.
 ___
 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
>>>
>>>
>> --
>>
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev