[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue
Dave Abrahams
dabrahams at apple.com
Sun Jun 5 19:54:27 CDT 2016
on Thu Jun 02 2016, John McCall <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.
More fundamental reasons:
* `Array<Int>.size` is easily misinterpreted. The identifier
`MemoryLayout` was suggested in order to set the proper mental context
at the use site.
* I don't want “size,” “alignment,” and “spacing” appearing in the
code-completion list for every type.
* I can easily imagine users wanting to use static properties by these
names for their own types, with completely different meaning.
> But I agree that in the abstract a static property would be
> preferable.
>
> John.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
--
-Dave
More information about the swift-evolution
mailing list