Sent from my iPad
>> On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith <pgwsm...@gmail.com> wrote: >> I really like this idea. This IMO is lower level functionality than >> `type(of:)` (née dynamicType), so I think it makes sense for it to be >> grouped under its own domain, the MemoryLayout type. >> >> Plus MemoryLayout can be extended with new convenience methods. >> >> I’m fine with those old methods being removed, but I never use them so! Is >> it the same as calling type(of:) then using that with MemoryLayout? I >> imagine they could be fixit’d easily, and that they compile down to the same >> underlying code. > > I'm actually souring to the idea. It goes in the diametrically opposite > direction from dynamicType. There, something was changed from being > property-like to being function-like. Here, Dave's proposal would take > something that's a function and turn it into a property. Hmm. That's not a fair comparison though. With dynamicType we removed a "magic" property visible on all types, which isn't something you can write and turned it into a function (which is obviously something you can write). Dave's MemoryLayout creates a new type to bundle together related items which makes their semantic relationship more clear. It also receives the type via a generic argument rather than a function argument and makes the properties static. That is more representative of what is actually happening and could help to prevent confusion. If we really need an 'ofValue' option that infers T from a value the properties on MemoryLayout could also be made available as instance properties and it could have an initializer that accepts an instance to T and throws the value away. However, I'm not at all convinced this is necessary. >>> On 2 Jun 2016, at 3:05 PM, Xiaodi Wu via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> 2. Dave A. and others expressed the opinion that these should probably not >>> be global functions; his preference was for: >>> >>> ``` >>> MemoryLayout<T>.size // currently sizeof() >>> MemoryLayout<T>.spacing // currently strideof() >>> MemoryLayout<T>.alignment // currently alignof() >>> ``` >>> >>> 3. Dave A. proposed that sizeofValue(), strideofValue(), and alignofValue() >>> are better off removed altogether. I don't know if people are going to be >>> happy about this idea. > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
