t; research in this area please find a way to embrace it.
>
> Also a proper active objects based OO system would be appealing.
>
> Suminda
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listi
e().slice_from(i+c.len_utf8_bytes()))
>
> It's quite complex, no better way to do ?
>
> Any future additional methods for String are planned ?
>
> Thanks
>
> --
> Christophe
>
>
>
>
>
> _______
> Rus
elf, key: &~str) -> bool {
> self.props.contains_key(key)
> }
> }
>
> what i am doing wrong ?
>
> Thanks
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-de
), but out-of-bound conditions are particularly
severe and deserves a solution. I would really appreciate better
solutions for the bounds check, but disabling the bounds check without
an alternative measure will considerably hurt the main goal of Rust.
--
-- Kang Seonghoon | Software Engineer, i
}
> continue h;
> }
> }
>
> This syntax only allows to jump at the beginning of a lexical block, and
> only to an larger scope, thus not infriging any static lexical rule.
To be exact, it is `'g: ...` and `break 'g;` respectively. Its
resemblance with th
>});
>
> Is there a clearer way?
>
> Thanks,
>
> Phil
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
--
-- Kang Seonghoon | Softwar
like that?
>
> Food for thought, at least.
I second to this. Indeed, we already have similar concerns about
externally-implemented `#[deriving]` (#11813, and somewhat tangently,
#11298), as syntax extensions don't have any clue about paths.
--
-- Kang Seonghoon | Software Eng
enjoying following the language and hope to use
> it as a safer replacement for C++ for latency sensitive code.)
>
> Cheers,
>
> Phil
>
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo
rks upload (and graphing)
>
> cheers,
>
> Hans Jørgen
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
--
-- Kang Seonghoon
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
--
-- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/
-- Opinions expressed in this email do not necessarily represent the
views of
__
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
--
-- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/
-- Opinions expressed in this email do not necessarily represent the
views
to the problem.
[1] https://github.com/mozilla/rust/issues/2498
2013/5/2 Steve Klabnik :
> I'm for this.
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
--
-- Kang Seonghoon | Soft
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
--
-- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/
-- Opinions expressed in this email do
t;> http://courteous.ly/yp3Zgd
>
>
>
>
> --
> /f
>
> I reject your reality and substitute my own.
> http://courteous.ly/yp3Zgd
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
;
> My reasons:
>
> 1. No wasted lines (unlike /** ... */ which wastes two lines).
> 2. If you include a code example inside the `///` comment, you can use
> `/* ... */` within the comment without triggering errors.
> 3. It just looks better to my eyes ;)
--
-- Kang Seonghoon
n() {
> println(Number::make_number():int.incr().to_str()); // 2
> }
>
> However, a cast to int with `as` would convert both uint and int to int
> and therefore it wouldn't help the typechecker enough.
>
> Patrick
--
-- Kang Seonghoon | Software Engineer, iPl
ll
be invalid then. I choose `iif!` instead because it is already used in
several languages for expression-level conditionals.
* I suggest not to implement two-argument version `iif!(x, y)` (which
is same as `iif!(x, y, ())` by the definition). We don't want this
form to be used for general
be rewritten in terms of
$+ I think.
...Any thoughts?
--
-- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/
-- Opinions expressed in this email do not necessarily represent the
views of my employer.
--
___
Rust-dev ma
18 matches
Mail list logo
