[swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines
Xiaodi Wu
xiaodi.wu at gmail.com
Wed Jun 29 16:59:15 CDT 2016
On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris at mac.com> wrote:
> That’s the “as proposed” usage for getting the size of a value (from
> https://gist.github.com/erica/57a64163870486468180b8bab8a6294e)
>
> // Types
> MemoryLayout<Int>.size // 8
> MemoryLayout<Int>.arraySpacing // 8
> MemoryLayout<Int>.alignment // 8
> // Valuelet x: UInt8 = 5
> MemoryLayout(x).dynamicType.size // 1
> MemoryLayout("hello").dynamicType.arraySpacing // 24
> MemoryLayout(29.2).dynamicType.alignment // 8
>
>
>
> At least, I *thought* that was the latest version of the proposal. Maybe
> I’ve gotten confused.
>
There must be a typo in these examples. `MemoryLayout(x.dynamicType).size`
perhaps?
>
> - Dave Sweeris
>
>
> On Jun 29, 2016, at 4:36 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>
>
> On Wed, Jun 29, 2016 at 4:29 PM, David Sweeris via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> (While I was typing this up, I realized that the exact usage you’re
>> worried about, “MemoryLayout(Int.self).size” won’t compile, since
>> `MemoryLayout` currently doesn’t have instance properties. If you’re
>> worried about someone incorrectly typing out
>> “MemoryLayout(Int.self).dynamicType.size”, though…)
>>
>> I made a rather critical typo in my earlier reply. It should’ve been
>> “init(_: T.Type)”, instead of “init(_: T.self)”, which is to say this:
>> extension MemoryLayout { // assuming `MemoryLayout<T>` is already
>> defined as proposed
>> public init(_ : T.Type) {} // makes it so that
>> `MemoryLayout(T.self)` still has the correct type for `T`
>> }
>>
>> Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
>> // without `init(_ : T.Type)` defined
>> MemoryLayout<Int8>.size // 1, correct
>> MemoryLayout(Int8.self).dynamicType.size // 8, almost certainly
>> wrong
>> //MemoryLayout(Int8).dynamicType.size // error
>> MemoryLayout(0 as Int8).dynamicType.size // 1, correct
>> MemoryLayout<Int8.Type>.size // 8, correct
>> MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is
>> oddly worded
>> //MemoryLayout(Int8.Type).dynamicType.size // error
>>
>> // with `init(_ : T.Type)` defined
>> MemoryLayout<Int8>.size // 1, correct
>> MemoryLayout(Int8.self).dynamicType.size // 1, almost certainly
>> correct
>> MemoryLayout(Int8).dynamicType.size // 1, almost certainly
>> correct
>> MemoryLayout(0 as Int8).dynamicType.size // 1, correct
>> MemoryLayout<Int8.Type>.size // 8, correct
>> MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is
>> oddly worded
>> MemoryLayout(Int8.Type).dynamicType.size // 8, correct
>>
>> The only value that changes (aside from the errors) is the one “typo”
>> that you were worried about.
>>
>> Do this change your mind?
>>
>
> These examples make no sense to me. Why are we asking for the size of the
> dynamicType of MemoryLayout?
>
>
>>
>>
>>
>> On Jun 29, 2016, at 12:34 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>>
>>
>>
>> on Wed Jun 29 2016, David Sweeris <davesweeris-AT-mac.com
>> <http://davesweeris-at-mac.com/>> wrote:
>>
>> Would adding a "init(_: T.self) {...}" solve that issue?
>>
>>
>> ? I don't see how.
>>
>>
>> Sent from my iPhone
>>
>> On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> 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.
>>
>>
>> --
>> Dave
>>
>>
>>
>> - Dave Sweeris
>>
>>
>> _______________________________________________
>> 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/20160629/0dd9bf52/attachment.html>
More information about the swift-evolution
mailing list