+1 on #3 3. MemoryLayout<Int>.size http://i.gifntext.com/29412-number-3-my-lord.gif <http://i.gifntext.com/29412-number-3-my-lord.gif>
> On Jun 6, 2016, at 3:37 PM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > on Mon Jun 06 2016, Nate Cook <natecook-AT-gmail.com> wrote: > >> I'd like to cast another vote in favor of something like the >> MemoryLayout struct. In general, people aren't always making the right >> choice about which of these values to use. Combining them into one >> data type would mean they see that there are three related values and >> can find out when to use which easily. >> >> Would MemoryLayout need to be generic? Accessing a static property on >> a generic type doesn't seem as straightforward as a function call or >> the properties of a struct. I think I'd prefer something closer to the >> way Mirror works, but really, I defer to those with stronger >> convictions / actual reasons: >> >> func type<T>(of value: T) -> T.Type { >> return T.self >> } >> >> struct MemoryLayout { >> let size: Int >> let stride: Int >> let alignment: Int >> >> init<T>(of type: T.Type) { > > I see no need for an argument label here. > >> size = sizeof(type) >> stride = strideof(type) >> alignment = alignof(type) >> } >> } > > These are all possible syntaxes, but I think #3 is best: > > 1. MemoryLayout(Int.self).size > 2. memoryLayout(Int.self).size > 3. MemoryLayout<Int>.size > > I don't see any advantage of #1 over #2, and there's no need at all to > define a new nominal type if we only want #2: > > func memoryLayout<T>(_ T.type) -> (size: Int, stride: Int, alignment: Int) { > // implementation > } > >> Nate >> >>> On Jun 5, 2016, at 7:54 PM, Dave Abrahams via swift-evolution >>> <[email protected]> wrote: >>> >>> on Thu Jun 02 2016, John McCall <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> On Jun 2, 2016, at 1:43 PM, Russ Bishop <[email protected]> wrote: >>>> >>>> On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution >>>> <[email protected]> >>>> wrote: >>>> >>>> I still think the value-based APIs are misleading and that it would be >>>> better to ask people to just use a type explicitly. >>>> >>>> John. >>>> >>>> I agree; in fact why aren’t these properties on the type itself? The type >>>> is what matters; why can’t the type just tell me it’s size? >>>> Having free functions or magic operators seems to be another holdover from >>>> C. >>>> >>>> Int.size >>>> Int.alignment >>>> Int.spacing >>>> >>>> let x: Any = 5 >>>> type(of: x).size >>>> >>>> The compiler should be able to statically know the first three values and >>>> inline them. The second is discovering the size dynamically. >>>> >>>> Two reasons. The first is that this is a user-extensible namespace via >>>> static members, so it's somewhat unfortunate to pollute it with names >>>> from the library. The second is that there's currently no language >>>> mechanism for adding a static member to every type, so this would have >>>> to be built-in. >>> >>> More fundamental reasons: >>> >>> >>> * `Array<Int>.size` is easily misinterpreted. The identifier >>> `MemoryLayout` was suggested in order to set the proper mental context >>> at the use site. >>> >>> * I don't want “size,” “alignment,” and “spacing” appearing in the >>> code-completion list for every type. >>> >>> * I can easily imagine users wanting to use static properties by these >>> names for their own types, with completely different meaning. >>> >>>> But I agree that in the abstract a static property would be >>>> preferable. >>>> >>>> John. >>>> >>>> _______________________________________________ >>>> 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> >>>> >>> >>> -- >>> -Dave >>> >>> _______________________________________________ >>> 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> > > -- > Dave > _______________________________________________ > 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
