<html><body><div id="edo-message"><div>Yeah it definitely should be it's own proposal. It's just that add we add new Unsafe types, the naming is becoming ridiculous and doesn't clearly express the information developer's need to know when using the types.</div><div><br></div><div>It's always been a bit iffy, but as I look at the proposal, DaveA's logic that it should be called Unsafe(Mutable)RawBufferPointer is sound but I really don't like that name.</div><div><br></div><div>I'll start a thread to pitch removing/renaming Unsafe.</div><div><br></div><div>Karl<br></div></div><div id="edo-original"><div><br><br><blockquote type="cite" style="margin:1ex 0 0 0;border-left:1px #ccc solid;padding-left:0.5ex;"><div>On Sep 7, 2016 at 3:27 pm, <<a href="mailto:rien@balancingrock.nl">Rien</a>> wrote:<br><br></div><div><pre>As much as I would like to get rid of the “Unsafe” prefix, for this change it should imo be considered “out of scope”.
<br>Since it is used for the other pointers, it should be used here also.
<br>
<br>Maybe a separate proposal to get rid of “Unsafe”?
<br>
<br>Rien
<br>
<br>> On 07 Sep 2016, at 14:48, Karl Wagner via swift-evolution <<a dir="ltr" href="mailto:swift-evolution@swift.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="2">swift-evolution@swift.org</a>> wrote:
<br>>
<br>> >> 1. It points into memory that it does not own. The developer must do something to to manage the memory’s lifetime.
<br>>
<br>> Isn't that just a pointer? Is it really necessary to say "unsafe" and "pointer"?
<br>>
<br>> And if we did want to make it explicit, perhaps we say "unowned" instead, to make it clear how it is unsafe. "RawBufferPointer"/"UnownedRawBufferPointer" sound pretty good to me. You can derive some pretty solid expectations from those names.
<br>>
<br>> Karl
<br>>
<br>>
<br>>> On Sep 6, 2016 at 10:59 pm, <Andrew Trick> wrote:
<br>>>
<br>>>
<br>>>> On Sep 2, 2016, at 7:36 PM, Karl via swift-evolution <<a dir="ltr" href="mailto:swift-evolution@swift.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="5">swift-evolution@swift.org</a>> wrote:
<br>>>>
<br>>>>> * Does this proposal fit well with the feel and direction of Swift?
<br>>>>
<br>>>> Yes, but I’m not sure about the “Unsafe” part of “UnsafeBytes” — what is unsafe about getting the byte-representation of a value?
<br>>>>
<br>>>> As I understand it, “Raw” is what we use for “untyped”, so might I suggest “RawBytes"?
<br>>>
<br>>> It’s annoying, but a strict requirement in Swift that any “unsafe” operation be marked with the word “Unsafe” either at that point or in some enclosing scope. Unsafe broadly refers to various forms of memory unsafety. Unsafe bytes is actually safe with respect to pointer aliasing but it is unsafe because
<br>>>
<br>>> 1. It points into memory that it does not own. The developer must do something to to manage the memory’s lifetime.
<br>>>
<br>>> 2. It does not perform bounds-checking in release mode.
<br>>>
<br>>> In both those respects, it’s just like UnsafeBufferPointer.
<br>>>
<br>>> -Andy
<br>> _______________________________________________
<br>> swift-evolution mailing list
<br>> <a dir="ltr" href="mailto:swift-evolution@swift.org" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="6">swift-evolution@swift.org</a>
<br>> <a dir="ltr" href="https://lists.swift.org/mailman/listinfo/swift-evolution" x-apple-data-detectors="true" x-apple-data-detectors-type="link" x-apple-data-detectors-result="7">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
<br>
<br></pre></div></blockquote></div></div></body></html>