[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue
xiaodi.wu at gmail.com
Thu Jun 2 20:03:13 CDT 2016
As I said above, I disagree. Unsafe things should have names that call
attention to themselves. Safe things should not, *especially* if they're
unsafe-adjacent. It's not useful in a line of code to have every part of it
competing for your attention merely because they're typically used in
conjunction with an unsafe operation. It's essential that the unsafe
operation itself stand out.
Ever see a doctor clicking their mouse faster than a video gamer to dismiss
20 warnings in a row on a computer screen? That's what happens when
everything unsafe-adjacent calls attention to itself.
On Thu, Jun 2, 2016 at 19:53 Matthew Johnson <matthew at anandabits.com> wrote:
> Sent from my iPad
> On Jun 2, 2016, at 4:25 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
> On the other hand, on its own sizeof() is not unsafe, and so the argument
> that it should be longer to call attention to itself (by analogy with
> UnsafePointer) isn't quite apt.
> These operations aren't themselves unsafe. But they are low level details
> that are not useful unless you are doing something that requires special
> care. A name that stands out more calls attention to the surrounding
> code. That is a good thing IMO.
> And I'm not sure we really want to encourage anyone else to be defining a
> global function named size(of:) anyway, so I wouldn't consider vacating
> that name for end-user purposes to be a meaningful positive.
> On Thu, Jun 2, 2016 at 16:15 Tony Allevato <allevato at google.com> wrote:
>> Given that these are fairly low-level values with very specialized uses,
>> I definitely agree that they should be somehow namespaced in a way that
>> doesn't cause us to make very common words unusable for our users.
>> Even size(of:) seems more general to me than I'd like. I'd like to see
>> the word "memory" as part of the name somehow, whether it's a wrapping type
>> or a function prefix of some sort. These values are specialized; we don't
>> need to optimize typing them, IMO.
>> On Thu, Jun 2, 2016 at 2:06 PM Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>> On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>> On Jun 2, 2016, at 1:43 PM, Russ Bishop <xenadu at gmail.com> wrote:
>>>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>> I still think the value-based APIs are misleading and that it would be
>>>> better to ask people to just use a type explicitly.
>>>> I agree; in fact *why aren’t these properties on the type itself*? The
>>>> type is what matters; why can’t the type just tell me it’s size?
>>>> Having free functions or magic operators seems to be another holdover
>>>> from C.
>>>> let x: Any = 5
>>>> type(of: x).size
>>>> The compiler should be able to statically know the first three values
>>>> and inline them. The second is discovering the size dynamically.
>>>> Two reasons. The first is that this is a user-extensible namespace via
>>>> static members, so it's somewhat unfortunate to pollute it with names from
>>>> the library. The second is that there's currently no language mechanism
>>>> for adding a static member to every type, so this would have to be
>>>> built-in. But I agree that in the abstract a static property would be
>>> In the earlier conversation, it was pointed out (by Dave A., I think?)
>>> that examples such as Array.size show how this solution can get confusing.
>>> And even though there aren't fixed-length arrays in Swift, those may come
>>> one day, making the syntax even more confusing.
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution