Well, as I understand it, it's not actually possible to write your own type(of:), so we're going from a "magic" property to a "magic" function at least for now.
I'm most alarmed that one implication of the MemoryLayout proposal is loss of the `ofValue` family of functions. These functions don't fit with the design: imagine, what is `MemoryLayout<Double>.size(ofValue: Float(42))`? But the response seems to be that these functions don't seem necessary at all and should be removed. "I don't see a use for it" is an insufficient justification for a feature removal. Looking to other languages, C# has sizeof as a static property but tellingly offers the equivalent of sizeofValue (well, strideofValue) as a function in a different module. Essentially every other C-family language that exposes pointers to the user offers both of and ofValue equivalents. The question is, how does a user with existing code using sizeofValue() migrate to Swift 3? I do not see a viable answer with the MemoryLayout design. On Thu, Jun 2, 2016 at 8:03 AM Matthew Johnson <[email protected]> wrote: > > > Sent from my iPad > > On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith <[email protected]> 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 < >> [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
