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

[Dave Abrahams]

on Thu Jun 02 2016, John McCall <swift-evolution at swift.org> wrote:

>  On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org>
>  wrote:
>
>  On Jun 2, 2016, at 10:38 AM, Xiaodi Wu <xiaodi.wu at gmail.com> 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
>
> There's no good reason for this type to be generic. 

I can think of at least two: improved syntax at the use-site and lower
API surface area.  But I'm comparing a design I had in my mind for
MemoryLayout with the only other alternative I've thought of.  Maybe
you'd care offer an alternative design.

> It should be non-generic and require the use of the instance
> properties.

Instance properties?  Why should we ever create an instance of this
thing?

> It's actively harmful for this type to appear to be computed from a
> value. 

I agree.

> The layout is not in any way tied to the dynamic type of the value —
> for example, it is not the instance layout of the most-derived class
> or the value layout of the dynamic type of an
> existential. Furthermore, saying that it is computed from a value
> means that attempting to compute it from a type will succeed using the
> layout of the metatype, which seems like a catastrophic failure of API
> design.
>
> John.
>
>  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
>
>  _______________________________________________
>  swift-evolution mailing list
>  swift-evolution at swift.org
>  https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave