> That's not how Rust defines `unsafe`. It's open to misuse, and the
> compiler will happily point out that it's not being used correctly via
> the unnecessary unsafe lint.
>
If that's the case, do you think there's some worth in allowing the
programmer to define arbitrary generic safety types?
E
On 21/09/14 04:27 PM, Evan G wrote:
> Personally, I feel "safety" generalizes pretty well to "any concept
> that should be called out explicitly as unsafe"--not just memory
> safety.
That's not how Rust defines `unsafe`. It's open to misuse, and the
compiler will happily point out that it's not be
On Sep 21, 2014, at 1:27 PM, Evan G wrote:
> Personally, I feel "safety" generalizes pretty well to "any concept
> that should be called out explicitly as unsafe"--not just memory
> safety.
The difference is that the current uses of `unsafe` are guarding things that
cause a program to not have
On 21/09/14 16:27 -0400, Evan G wrote:
Personally, I feel "safety" generalizes pretty well to "any concept
that should be called out explicitly as unsafe"--not just memory
safety.
You can feel that all you want, but memory safety is reasonably
straightforward to define in a general context, wh
Personally, I feel "safety" generalizes pretty well to "any concept
that should be called out explicitly as unsafe"--not just memory
safety.
On Sun, Sep 21, 2014 at 4:12 PM, Daniel Micay wrote:
> On 21/09/14 05:57 AM, Simon Sapin wrote:
>> On 21/09/14 07:34, Daniel Micay wrote:
>>> It's not inten
On 21/09/14 05:57 AM, Simon Sapin wrote:
> On 21/09/14 07:34, Daniel Micay wrote:
>> It's not intended to be used for anything other than memory safety.
>
> It’s also used to maintain invariants, such as the bytes inside a String
> being valid UTF-8: String::push_bytes() is unsafe, but
> String::p
Thanks that was a very illuminating example.
As for iterating over pairs would it be possible to have an iterator
that gives both:
1. A mutable reference to the next element
2. An iterator over the rest of the elements
the idea would be to be able to write
for (ele_i, rest) in list.iterator() {
Hi,
are there any plans to implement complete common safe bindings to LLVM?
I know about existing ones, but they have problems:
-- they are low level unsafe extern C functions, it would be nice to have LLVM
API wrapped in safe idiomatic rust code
-- some parts are wrapped in safe rust code, bu
You can break memory safety in a single thread if you allow multiple
mutable references to the same object. Consider an enum like this:
enum Foo {
Pointer(Box),
Integer(i32)
}
Take one reference to the boxed `T` inside a `Foo` of the `Pointer`
variant. It doesn't even have to be mutable.
On 21/09/14 07:34, Daniel Micay wrote:
It's not intended to be used for anything other than memory safety.
It’s also used to maintain invariants, such as the bytes inside a String
being valid UTF-8: String::push_bytes() is unsafe, but
String::push_str() is not.
--
Simon Sapin
__
On Sun, Sep 21, 2014 at 2:02 AM, Cameron Zwarich
wrote:
> The usual solution to this particular problem in typed languages is to
> make a new type wrapping sanitized strings, use some feature of the
> language (e.g. abstract types or module privacy) to restrict the creation
> of instances of this
On Sep 20, 2014, at 11:29 PM, Tony Arcieri wrote:
> He suggested using unsafe to call out when a SQL query is being made with a
> raw string.
>
> On the one hand I really liked the clarity of calling out passing a raw
> string to a SQL driver as being inherently unsafe, but on the other hand i
12 matches
Mail list logo
