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

[Nate Cook]

I'd like to cast another vote in favor of something like the MemoryLayout struct. In general, people aren't always making the right choice about which of these values to use. Combining them into one data type would mean they see that there are three related values and can find out when to use which easily.

Would MemoryLayout need to be generic? Accessing a static property on a generic type doesn't seem as straightforward as a function call or the properties of a struct. I think I'd prefer something closer to the way Mirror works, but really, I defer to those with stronger convictions / actual reasons:

func type<T>(of value: T) -> T.Type {
    return T.self
}

struct MemoryLayout {
    let size: Int
    let stride: Int
    let alignment: Int
    
    init<T>(of type: T.Type) {
        size = sizeof(type)
        stride = strideof(type)
        alignment = alignof(type)
    }
}
Nate

> On Jun 5, 2016, at 7:54 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> on Thu Jun 02 2016, John McCall <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160606/0436ce44/attachment.html>