on Tue Jun 28 2016, Hooman Mehr <[email protected]> wrote:
> How about we get rid of dynamicType by adding instance level properties as
> well:
>
> public struct MemoryLayout<T> {
>
> public static var size: Int { return sizeof(T) }
> public static var interval: Int { return strideof(T) }
> public static var alignment: Int { return alignof(T) }
>
> public var size: Int { return sizeof(T) }
> public var interval: Int { return strideof(T) }
> public var alignment: Int { return alignof(T) }
>
> init(_ : @autoclosure () -> T) {}
> }
>
> print(MemoryLayout<Int>.size) // 8
> print(MemoryLayout<Int>.interval) // 8
> print(MemoryLayout<Int>.alignment) // 8
>
> let x = 8
>
> print(MemoryLayout(x).size) // 8
> print(MemoryLayout(x).interval) // 8
> print(MemoryLayout(x).alignment) // 8
My worry is that people will write
MemoryLayout(Int.self).size
when they mean
MemoryLayout<Int>.size
(often because for some reason they don't like angle brackets).
I prefer to make the uncommon case much harder to write.
>
>> On Jun 28, 2016, at 5:08 PM, Dave Abrahams via swift-evolution
>> <[email protected]> wrote:
>>
>>
>> on Tue Jun 28 2016, Brandon Knope <bknope-AT-me.com> wrote:
>>
>>> Isn't dynamicType possibly changing soon to a method?
>>
>> A free function, I think.
>>
>>> This could look much different
>>
>> Yes, It will be uglier. But this very uncommon case is not important to
>> optimize for beauty.
>>
>> --
>> Dave
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
--
Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
