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

[Dave Abrahams]

on Mon Jun 06 2016, Nate Cook <natecook-AT-gmail.com> wrote:

> 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) {

I see no need for an argument label here.

>         size = sizeof(type)
>         stride = strideof(type)
>         alignment = alignof(type)
>     }
> }

These are all possible syntaxes, but I think #3 is best:

1. MemoryLayout(Int.self).size
2. memoryLayout(Int.self).size
3. MemoryLayout<Int>.size

I don't see any advantage of #1 over #2, and there's no need at all to
define a new nominal type if we only want #2:

 func memoryLayout<T>(_ T.type) -> (size: Int, stride: Int, alignment: Int) {
    // implementation
 }

> 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>

-- 
Dave