[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu]

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.

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.
>>>
>>> John.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>     Int.size
>>>     Int.alignment
>>>     Int.spacing
>>>
>>>     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
>>> preferable.
>>>
>>
>> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160602/d2019eea/attachment.html>