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
> <[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>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
