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

Xiaodi Wu xiaodi.wu at gmail.com
Thu Jun 2 16:05:50 CDT 2016


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160602/4b2d2998/attachment.html>


More information about the swift-evolution mailing list