[swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

[Xiaodi Wu]

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 <matthew at anandabits.com>
wrote:

>
>
> Sent from my iPad
>
> On Jun 2, 2016, at 12:27 AM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Thu, Jun 2, 2016 at 12:24 AM, Patrick Smith <pgwsmith at 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 at 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 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/20160602/a51ed76a/attachment.html>