> On Jun 2, 2016, at 10:38 AM, Xiaodi Wu <[email protected]> wrote:
>
> 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.
No, but you *can* write `func foo<T>(_ t: T)` which accepts any value (you
*cannot* write a property that is available for all properties - that would
require the ability to write `extension Any`. This is the distinction I am
making. Of course the implementation is compiler magic no matter how we
express it syntactically. But we can make it *appear* just like it might if
the implementation *wasn’t* compiler magic. That makes it fit into the
language better IMO and was the biggest motivator for changing `dynamicType`.
>
> 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.
Going with MemoryLayout *does not* mean we would have to give up the value
functions if we don’t want to:
struct MemoryLayout<T> {
init() {}
init(t: T) { /* throw away the value */ }
// we could omit the static properties and require
// writing MemoryLayout<Int>() if we don’t like the duplication
static let size: Int
static let spacing: Int
static let alignment: Int
let size: Int
let spacing: Int
let alignment: Int
}
let size = MemoryLayout<Int>.size
let sizeOfValue = MemoryLayout(42).size
>
> On Thu, Jun 2, 2016 at 8:03 AM Matthew Johnson <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> Sent from my iPad
>
> On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith <[email protected]
>> <mailto:[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] <mailto:[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] <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
