I encountered inconsistencies like this quite a bit while coding up my
first program in Rust[0]. Glad to see this addressed; the current API
forces some really awkward syntax, I think.
As shown in that file, the time crate also requires strange syntax, in
my opinion. Ideally arguments are always "plain-old-strings", ie:
this_should("always", "work");
this_should_not(&"be".to_string(), ["required".to_string()]);
But there may be more to the story than I'm aware of.
-- Nick
[0]: https://github.com/uutils/coreutils/blob/master/touch/touch.rs#L111
On Mon, May 26, 2014 at 9:38 PM, Kevin Ballard <[email protected]> wrote:
> Sure, that seems like a pretty easy job to tackle. You should audit the
> whole getopts API to see where it uses String inappropriately. Any &[String]
> parameters should probably be &[S] where <S: Str>, and any bare String
> parameters (if any) should probably be &str.
>
> -Kevin
>
> On May 26, 2014, at 6:29 PM, Gulshan Singh <[email protected]> wrote:
>
> On Mon, May 26, 2014 at 2:56 PM, Kevin Ballard <[email protected]> wrote:
>>
>> All the methods that take &[String] should probably be rewritten to be
>> generic with <S: Str> and take &[S] instead, which will allow taking either
>> a slice of Strings or a slice of &str's.
>
>
> I've been wanting to contribute to Rust for a while. This seems like the
> right thing to do and I don't think it's a hard change. Should I go ahead
> and make it?
>
> --
> Gulshan Singh
> University of Michigan, Class of 2015
> College of Engineering, Computer Science Major
> [email protected] | 248.961.6317
> Alternate E-mail: [email protected]
>
>
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
