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

Matthew Johnson matthew at anandabits.com
Thu Jun 2 19:53:00 CDT 2016



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.
>>>>>> 
>>>>>> 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
> _______________________________________________
> 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/0f808b99/attachment.html>


More information about the swift-evolution mailing list