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

[Jose Cheyo Jimenez]

+1 on #3
3. MemoryLayout<Int>.size

http://i.gifntext.com/29412-number-3-my-lord.gif <http://i.gifntext.com/29412-number-3-my-lord.gif>

> On Jun 6, 2016, at 3:37 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 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
> _______________________________________________
> 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/20160606/adb07620/attachment.html>