On 10/29/2011 05:06 AM, David Rajchenbach-Teller wrote:
I disagree. I would expect print to be something that writes to
stdout. As I understand it, log is a specialised debug/trace facility
which is built-in and configurable. For example if you write log
"hello world" it won't print anything unless RUST_LOG is set. I don't
think it would be too mind blowing to introduce std::io::stdout() in
the Hello World program.
Why not a "print" that (unconditionally) prints to stdout?
In my experience "log_err" is for quick and dirty "printf debugging", so
stderr seems appropriate to me. It's not intended to be the main way for
command-line programs to get stuff on the screen. It's not ideal for
that purpose anyway, since it's polymorphic and you typically don't want
to show the equivalent of toSource() output to end users.
Perhaps "show" would be a better name, to make it clear that it's a
debugging tool?
Given what I just said above, maybe our hello world shouldn't encourage
poor practices and should import the print function from the standard
library. I'm a little concerned from a developer ergonomics/marketing
perspective that we require an import statement for hello world (note
that not even Java requires this), but I suppose it can't be helped
unless we really want to have a std::pervasives module that's imported
by default.
Between "enum" and "union", I tend to favor "enum", for a simple
reason:
- attempting to use a variant as a C-style or Java-style enum will work
flawlessly;
- by opposition, attempting to use a variant as a C-style union will
fail for reasons that will be very unclear for C programmers.
I'd prefer to not use either, because variants are really a combination
of enums and unions in the C/C++ sense. If we use "enum", the "union"
aspect of variants will look weird to C folks; if we use "union", the
"enum" aspect will likewise look weird.
Patrick
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
