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
>> <[email protected]> wrote:
>>
>> on Thu Jun 02 2016, John McCall <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> On Jun 2, 2016, at 1:43 PM, Russ Bishop <[email protected]> wrote:
>>>
>>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution
>>> <[email protected]>
>>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>
>> --
>> -Dave
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
--
Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
