[Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

[Chris_Lattner]

Hello Swift community,

The review of "SE-0101: Rename sizeof and related functions to comply with API Guidelines" begins now and runs through June 27. The proposal is available here:

  swift-evolution/0101-standardizing-sizeof-naming.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

[Joe_Groff]

Regarding the issue of existential metatypes with sizeof:

Pyry Jahkola points out one instance where the memorySize(type(of: …)) workaround won't work. When the value is an existential, it's illegal to ask for the size of its dynamic type: the result can't be retrieved at compile time:

// Swift 2.2, 64-bit
let i = 123
print(sizeofValue(i)) //=> 8
let c: CustomStringConvertible = i
print(sizeofValue(c)) //=> 40
print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an argument list of type '(CustomStringCo
This could be enabled by having sizeof and friends formally take an Any.Type instead of <T> T.Type. (This might need some tweaking of the underlying builtins to be able to open existential metatypes, but it seems implementable.)

-Joe

[Scott_James_Remnant]

I’ve given this a pretty thorough couple of readings, and experimented with the different options in my own code.

Global functions in Swift are a rare thing, in general the language prefers not to have them, so where we do have them I feel it’s important to get them right. Addressing them is, to me, an significant improvement to Swift and the proposal makes good steps towards that.

I do have some comments.

It is clear to me that the purpose of functions that return details about the size in memory of a type, the alignment in memory of a type, and the distance between memory of two values of a given type, are consistently within the realm of dealing with types. For example, the “what is distance between memory of a value” makes no sense as a question, the only way to make that question make sense is to instead say “what is the distance between memory of two values of the type of a value.” Likewise “what is the size in memory of the type of a value,” and “what is the alignment in memory of the type of a value.”

Allowing these functions to operate on values is really just a shortcut, these functions should naturally operate on types.

To that end, I would prefer that the “ofValue” variations be removed, and SE-0096 to be preserve as-is.

The proposal brings up the issue that you cannot ask for the size of an existential type, but is that actually an issue? The purpose of these functions is to permit memory allocation, low-level memory manipulation, etc. Is there ever a situation where it is valid to do this on an existential type? Isn’t the very error here a sign that the type you’re attempting to manipulate isn’t one that you should be performing low-level memory manipulation for?

Scott

[Lmpessoa (Leonardo Pessoa)]

Hello Swift community,

The review of "SE-0101: Rename sizeof and related functions to comply with API Guidelines" begins now and runs through June 27. The proposal is available here:

        https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md

        * What is your evaluation of the proposal?

After a carefull review of the proposal, I will be obligated to
decline it. After studying the proposal I ended up thinking I was
writing more code to get the data and in comparison with dynamicType
-> type(of:) it lead me to think at first the proposal would suggest
renaming size* functions to size(of*:) and so forth, which would seem
to go more towards the compared proposal (SE-0096). This idea doesn't
even made into the alternatives considered and I think it would making
reading and understanding the code much clearer than the proposed
nested function calls.

        * Is the problem being addressed significant enough to warrant a change to Swift?

I'm not sure. Given the reasoning I'd say yes but given proposal
SE-0096 I'd say yes only if the new function names were to be
size(of*:), stride(of*:) and align(of*:) and thus not depending of the
nested result of type(of*:).

        * Does this proposal fit well with the feel and direction of Swift?

I don't think so. As I said, when I finished reading the proposal, I
ended up thinking I was writing more code in the new version and it
didn't seem very clear to me what was the size I was getting.
Moreover, it seems I'll always have to invoke these functions to the
result of type(of*:) which would be unnecessary redundant code.

        * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Many languages (like C/C++, C#, D) have both sizeof and typeof and in
most these two functions have similar names and syntaxes. In this case
I believe making them different makes it hard to discover those
functions exist and relate their purpose.

        * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick study was enough for me.

L

···

On 21 June 2016 at 14:03, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

[Brent_Royal-Gordon]

  * What is your evaluation of the proposal?

Generally in support, with two small exceptions:

1. I think the type variants should have the parameter label `of`. `memorySize(of: Int.self)` reads grammatically (other than the hopefully soon-to-be-vestigial `self`); `memorySize(Int.self)` does not.

2. I am not convinced that the `ofValue` variants are valuable enough to keep, although they do help support the (I think necessary, though I could probably be convinced otherwise now that these three all have a `memory` prefix) change to `type(ofValue:)`.

(Actually, I'm now considering the idea that these should be `valueSize(of: T.Type)`, etc., since they measure only the size of the immediate value, not any objects that value might reference. But that thought is underdeveloped, so I'm not ready to stand behind it.)

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes; these are inconsistent with the API guidelines.

  * Does this proposal fit well with the feel and direction of Swift?

Yes.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I like that it's a little clearer what sort of "size" is meant; people are unlikely to imagine this will tell them an array's length, for instance.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading.

···

--
Brent Royal-Gordon
Architechies

[anandabits (Matthew Johnson)]

  * What is your evaluation of the proposal?

-1. I prefer the MemoryLayout struct approach that Dave Abrahams has suggested. The proposed names retain the the disadvantage of several top level names and introduce a new disadvantage that they are not directly related to familiar terms of art (sizeof from C, etc).

  * Is the problem being addressed significant enough to warrant a change to Swift?

I don’t think it is a critical change given the current names are related to terms of art. If we are going to make a change I think it is better to reduce the number of top level names and make the relationship of them clear by making them members of a type.

  * Does this proposal fit well with the feel and direction of Swift?

It fits the Swift 3 directive to do any breaking change bike shedding now. However, the overall direction of Swift is away from top level functions without a compelling reason that a top level function is necessary. I don’t think these cases are compelling.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

They break the tie to familiar naming from other languages.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Participated quite a bit in the initial discussion and read the final proposal.

···

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Erica_Sadun]

While I'm not a huge fan of Dave A's generic struct approach (for reasons detailed in the proposal), this could resolve one major issue I currently have with his alternative.

-- E

···

On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Regarding the issue of existential metatypes with sizeof:

Pyry Jahkola points out one instance where the memorySize(type(of: …)) workaround won't work. When the value is an existential, it's illegal to ask for the size of its dynamic type: the result can't be retrieved at compile time:

let i = 123
let c: CustomStringConvertible = i
print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an argument list of type '(CustomStringCo
This could be enabled by having sizeof and friends formally take an Any.Type instead of <T> T.Type. (This might need some tweaking of the underlying builtins to be able to open existential metatypes, but it seems implementable.)

[dabrahams (Dave Abrahams)]

Would it be as fully specializable down to a compile-time constant?

···

on Tue Jun 21 2016, Joe Groff <swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org> wrote:

Regarding the issue of existential metatypes with sizeof:

Pyry Jahkola points out one instance where the memorySize(type(of: …))
workaround won't work. When the value is an existential, it's illegal
to ask for the size of its dynamic type: the result can't be retrieved
at compile time:

// Swift 2.2, 64-bit
let i = 123
print(sizeofValue(i)) //=> 8
let c: CustomStringConvertible = i
print(sizeofValue(c)) //=> 40
print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an argument list of type '(CustomStringCo
This could be enabled by having sizeof and friends formally take an
Any.Type instead of <T> T.Type. (This might need some tweaking of the
underlying builtins to be able to open existential metatypes, but it
seems implementable.)

--
Dave

[Joe_Groff]

Seems like it ought to be. sizeof() is just a transparent wrapper around Builtin.sizeof IIRC, and we can control the codegen of the builtin.

-Joe

···

On Jun 21, 2016, at 1:23 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Tue Jun 21 2016, Joe Groff <swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org> wrote:

Regarding the issue of existential metatypes with sizeof:

Pyry Jahkola points out one instance where the memorySize(type(of: …))
workaround won't work. When the value is an existential, it's illegal
to ask for the size of its dynamic type: the result can't be retrieved
at compile time:

// Swift 2.2, 64-bit
let i = 123
print(sizeofValue(i)) //=> 8
let c: CustomStringConvertible = i
print(sizeofValue(c)) //=> 40
print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an argument list of type '(CustomStringCo
This could be enabled by having sizeof and friends formally take an
Any.Type instead of <T> T.Type. (This might need some tweaking of the
underlying builtins to be able to open existential metatypes, but it
seems implementable.)

Would it be as fully specializable down to a compile-time constant?

[dabrahams (Dave Abrahams)]

Some of the examples used to justify avoiding that approach look
wrong or overly complicated to me. Am I missing something?

    let errnoSize = MemoryLayout.init(t: errno).size

    _class_getInstancePositiveExtentSize(bufferClass) ==
    MemoryLayout<_HeapObject.self>.size

wouldn't that be:

    let errnoSize = MemoryLayout(errno).size

    _class_getInstancePositiveExtentSize(bufferClass) ==
    MemoryLayout<_HeapObject>.size

?

Once you fix those issues, I don't find my proposal to hurt
readability at all. One has to put those examples into their actual
contexts rather than packing them all next to one another, to evaluate
it fairly.

Finally, I still object to doubling the API surface area just so you can
pass values instead of types to these functions. Having three global
functions is acceptable, but six is too many, and arguably, having a
single type would be better.

···

on Tue Jun 21 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Regarding the issue of existential metatypes with sizeof:

Pyry Jahkola points out one instance where the memorySize(type(of:

…)) workaround won't work. When the value is an existential, it's
illegal to ask for the size of its dynamic type: the result can't be
retrieved at compile time:

let i = 123
let c: CustomStringConvertible = i
print(sizeof(c.dynamicType)) // error: cannot invoke 'sizeof' with an argument list of type '(CustomStringCo
This could be enabled by having sizeof and friends formally take an
Any.Type instead of <T> T.Type. (This might need some tweaking of
the underlying builtins to be able to open existential metatypes,
but it seems implementable.)

While I'm not a huge fan of Dave A's generic struct approach (for
reasons detailed in the proposal),

--
Dave

[Erica_Sadun]

* I sourced my examples from the stdlib. That one's from ManagedBuffer.swift.
Only qualification was that I was looking for examples of sizeof.

* In regard to offering both of and ofValue, I agree: I'd rather offer half the surface area,
especially since Joe says the main issue is technically avoidable.

* I don't like having to scan past the MemoryLayout and the type in question to
get to the member name that defines what property is requested. You have to read it back
to front. I find that to be a human factors limitation that makes it less desirable to use.

* At the same time, what I do like about the struct is that it's extensible without introducing
standalone functions (and shrinks the number of functions that exist in the stdlib), and that
the properties express intrinsic characteristics of the memory layout of a given type. The
functions are measure-y. The properties are characteristic-y.

-- E

···

On Jun 21, 2016, at 2:36 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Tue Jun 21 2016, Erica Sadun <erica-AT-ericasadun.com <http://erica-at-ericasadun.com/&gt;&gt; wrote:

On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
This could be enabled by having sizeof and friends formally take an
Any.Type instead of <T> T.Type. (This might need some tweaking of
the underlying builtins to be able to open existential metatypes,
but it seems implementable.)

While I'm not a huge fan of Dave A's generic struct approach (for
reasons detailed in the proposal),

Some of the examples used to justify avoiding that approach look
wrong or overly complicated to me. Am I missing something?

   let errnoSize = MemoryLayout.init(t: errno).size

   _class_getInstancePositiveExtentSize(bufferClass) ==
   MemoryLayout<_HeapObject.self>.size

wouldn't that be:

   let errnoSize = MemoryLayout(errno).size

   _class_getInstancePositiveExtentSize(bufferClass) ==
   MemoryLayout<_HeapObject>.size

?

Once you fix those issues, I don't find my proposal to hurt
readability at all. One has to put those examples into their actual
contexts rather than packing them all next to one another, to evaluate
it fairly.

Finally, I still object to doubling the API surface area just so you can
pass values instead of types to these functions. Having three global
functions is acceptable, but six is too many, and arguably, having a
single type would be better.

[dabrahams (Dave Abrahams)]

This could be enabled by having sizeof and friends formally take an
Any.Type instead of <T> T.Type. (This might need some tweaking of
the underlying builtins to be able to open existential metatypes,
but it seems implementable.)

While I'm not a huge fan of Dave A's generic struct approach (for
reasons detailed in the proposal),

Some of the examples used to justify avoiding that approach look
wrong or overly complicated to me. Am I missing something?

   let errnoSize = MemoryLayout.init(t: errno).size

   _class_getInstancePositiveExtentSize(bufferClass) ==
   MemoryLayout<_HeapObject.self>.size

wouldn't that be:

   let errnoSize = MemoryLayout(errno).size

   _class_getInstancePositiveExtentSize(bufferClass) ==
   MemoryLayout<_HeapObject>.size

?

Once you fix those issues, I don't find my proposal to hurt
readability at all. One has to put those examples into their actual
contexts rather than packing them all next to one another, to evaluate
it fairly.

Finally, I still object to doubling the API surface area just so you can
pass values instead of types to these functions. Having three global
functions is acceptable, but six is too many, and arguably, having a
single type would be better.

* I sourced my examples from the stdlib. That one's from ManagedBuffer.swift.
  Only qualification was that I was looking for examples of sizeof.

I understand that, but I don't see how it's relevant. My point was that
these don't appear in code stacked one on top of another like that.

* In regard to offering both of and ofValue, I agree: I'd rather offer
half the surface area, especially since Joe says the main issue is
technically avoidable.

* I don't like having to scan past the MemoryLayout and the type in question to
get to the member name that defines what property is requested. You have to read it back
to front. I find that to be a human factors limitation that makes it
less desirable to use.

The “type in question” is very much relevant, just as in
`customers.count`, `customers` is relevant.

If I didn't think it would produce semantic confusion, these would be
static members e.g. `Array.memoryAlignment`, and you'd have to “scan
past” `Array`. It's a perfectly natural way to express a property of a
type.

* At the same time, what I do like about the struct is that it's
extensible without introducing standalone functions (and shrinks the
number of functions that exist in the stdlib), and that the properties
express intrinsic characteristics of the memory layout of a given
type. The functions are measure-y. The properties are
characteristic-y.

It even directly supports the -Value variants without expanding the
global API surface area, per

   MemoryLayout(errno).size

however, I don't think this is a good idea because of the potential for
confusion in cases like this:

   MemoryLayout(Int.self).size

···

on Tue Jun 21 2016, Erica Sadun <swift-evolution@swift.org> wrote:

On Jun 21, 2016, at 2:36 PM, Dave Abrahams <dabrahams@apple.com> wrote:
on Tue Jun 21 2016, Erica Sadun <erica-AT-ericasadun.com <http://erica-at-ericasadun.com/&gt;&gt; wrote:

On Jun 21, 2016, at 12:45 PM, Joe Groff via swift-evolution >>>> <swift-evolution@swift.org> wrote:

--
Dave

[Erica_Sadun]

I think

Array<Int>.memoryAlignment

is quite different to scan than

MemoryLayout(Array<Int>).alignment

(And I obviously like the former a lot more if it wouldn't produce
semantic confusion -- I assume you mean in the compiler and not
the reader of the code). That said, I think

memoryAlignment(Array<Int>.self)

reads better than

MemoryLayout(Array<Int>).alignment

You don't have to brainparse(TM by Cognition Inc) two other things
before arriving at alignment. The MemoryLayout feels more prominent
than it should. The alignment feels less prominent than it should.

I recognize we disagree on this, and we're unlikely to convince each other
on-list, which is why I tried hard to make sure that your alternative was
properly presented in the proposal. If I have made any errors in expressing
your design, its intent, and rationale, please let me know and I will edit the
proposal to fix.

-- E

···

On Jun 21, 2016, at 3:02 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

If I didn't think it would produce semantic confusion, these would be
static members e.g. `Array.memoryAlignment`, and you'd have to “scan
past” `Array`. It's a perfectly natural way to express a property of a
type.

[dabrahams (Dave Abrahams)]

If I didn't think it would produce semantic confusion, these would be
static members e.g. `Array.memoryAlignment`, and you'd have to “scan
past” `Array`. It's a perfectly natural way to express a property of a
type.

I think

Array<Int>.memoryAlignment

is quite different to scan than

MemoryLayout(Array<Int>).alignment

(And I obviously like the former a lot more if it wouldn't produce
semantic confusion -- I assume you mean in the compiler and not
the reader of the code).

No, I mean to the reader of the code. The former might easily be
interpreted as the memory alignment of the elements in the array, for
example. And the effect is much worse with the counterpart to sizeof.

That said, I think

memoryAlignment(Array<Int>.self)

reads better than

MemoryLayout(Array<Int>).alignment

You don't have to brainparse(TM by Cognition Inc) two other things
before arriving at alignment. The MemoryLayout feels more prominent
than it should. The alignment feels less prominent than it should.

I recognize we disagree on this,

We don't, actually. I agree that by themselves the APIs you are
proposing look better.

It's just that I don't think this part of the library API is important
enough, to enough people, that this readability is worth the additional
exposed surface area (and further exposure later on—I can easily imagine
a “minimumAlignment”). I would *much* rather keep this stuff corralled
in a single namespace where it can all be found.

So, my argument is really about the overall shape of the standard
library and its effect on ordinary users more than the look/feel of
these particular APIs.

and we're unlikely to convince each other on-list, which is why I
tried hard to make sure that your alternative was properly presented
in the proposal. If I have made any errors in expressing your design,
its intent, and rationale, please let me know and I will edit the
proposal to fix.

I think you represented it just fine, thanks... I just don't think
you're accounting for the big picture. These APIs are not like “map,”
“filter,” and “Dictionary.” They're specialty items that you should
only reach for when performing unsafe operations, mostly inside the guts
of higher-level constructs.

···

on Tue Jun 21 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

On Jun 21, 2016, at 3:02 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

--
Dave

[dwaite (David Waite)]

Late arrival to the thread, but wouldn’t these make sense to move these closer to the ‘Indexable’ Pointer/Buffer types, possibly onto them as static methods?

-DW

···

On Jun 21, 2016, at 6:06 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Tue Jun 21 2016, Erica Sadun <erica-AT-ericasadun.com <http://erica-at-ericasadun.com/&gt;&gt; wrote:

and we're unlikely to convince each other on-list, which is why I
tried hard to make sure that your alternative was properly presented
in the proposal. If I have made any errors in expressing your design,
its intent, and rationale, please let me know and I will edit the
proposal to fix.

I think you represented it just fine, thanks... I just don't think
you're accounting for the big picture. These APIs are not like “map,”
“filter,” and “Dictionary.” They're specialty items that you should
only reach for when performing unsafe operations, mostly inside the guts
of higher-level constructs.

[Erica_Sadun]

It's just that I don't think this part of the library API is important
enough, to enough people, that this readability is worth the additional
exposed surface area (and further exposure later on—I can easily imagine
a “minimumAlignment”). I would *much* rather keep this stuff corralled
in a single namespace where it can all be found.

See? That, I totally get.

I think you represented it just fine, thanks... I just don't think
you're accounting for the big picture. These APIs are not like “map,”
“filter,” and “Dictionary.” They're specialty items that you should
only reach for when performing unsafe operations, mostly inside the guts
of higher-level constructs.

--
Dave

Would you like me to edit it and flip the proposal then? Put the MemoryLayout in as primary,
mine as secondary, and add in text to explain that the motivation is less usability than serving
an unsafe API with minimal surface area?

-- E

···

On Jun 21, 2016, at 6:06 PM, Dave Abrahams <dabrahams@apple.com> wrote:

[dabrahams (Dave Abrahams)]

Well, the review has already started, so I don't think we ought to go
inverting the proposal now. Let's see how the discussion plays out. If
at the end, you agree with my point-of-view, you can say so and the
review manager and core team will take that into account.

···

on Tue Jun 21 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

On Jun 21, 2016, at 6:06 PM, Dave Abrahams <dabrahams@apple.com> wrote:

It's just that I don't think this part of the library API is important
enough, to enough people, that this readability is worth the additional
exposed surface area (and further exposure later on—I can easily imagine
a “minimumAlignment”). I would *much* rather keep this stuff corralled
in a single namespace where it can all be found.

See? That, I totally get.

I think you represented it just fine, thanks... I just don't think
you're accounting for the big picture. These APIs are not like “map,”
“filter,” and “Dictionary.” They're specialty items that you should
only reach for when performing unsafe operations, mostly inside the guts
of higher-level constructs.

--
Dave

Would you like me to edit it and flip the proposal then? Put the
MemoryLayout in as primary, mine as secondary, and add in text to
explain that the motivation is less usability than serving an unsafe
API with minimal surface area?

--
Dave

[Erica_Sadun]

No, I'd do edits on a gist page not in-place

-- E

···

On Jun 21, 2016, at 7:07 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Tue Jun 21 2016, Erica Sadun <erica-AT-ericasadun.com <http://erica-at-ericasadun.com/&gt;&gt; wrote:

On Jun 21, 2016, at 6:06 PM, Dave Abrahams <dabrahams@apple.com> wrote:

It's just that I don't think this part of the library API is important
enough, to enough people, that this readability is worth the additional
exposed surface area (and further exposure later on—I can easily imagine
a “minimumAlignment”). I would *much* rather keep this stuff corralled
in a single namespace where it can all be found.

See? That, I totally get.

I think you represented it just fine, thanks... I just don't think
you're accounting for the big picture. These APIs are not like “map,”
“filter,” and “Dictionary.” They're specialty items that you should
only reach for when performing unsafe operations, mostly inside the guts
of higher-level constructs.

--
Dave

Would you like me to edit it and flip the proposal then? Put the
MemoryLayout in as primary, mine as secondary, and add in text to
explain that the motivation is less usability than serving an unsafe
API with minimal surface area?

Well, the review has already started, so I don't think we ought to go
inverting the proposal now. Let's see how the discussion plays out. If
at the end, you agree with my point-of-view, you can say so and the
review manager and core team will take that into account.

[Patrick_Smith]

+1 to MemoryLayout, as I do like how it is namespaced under one type, which allows straight forward looking up of documentation. Writers from C or other sizeof() languages will able to see all available methods, allowing them to be educated to say not go for size but interval/spacing as the better choice.

Patrick

···

On 22 Jun 2016, at 10:26 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 21, 2016, at 6:06 PM, Dave Abrahams <dabrahams@apple.com <mailto:dabrahams@apple.com>> wrote:

It's just that I don't think this part of the library API is important
enough, to enough people, that this readability is worth the additional
exposed surface area (and further exposure later on—I can easily imagine
a “minimumAlignment”). I would *much* rather keep this stuff corralled
in a single namespace where it can all be found.

See? That, I totally get.

I think you represented it just fine, thanks... I just don't think
you're accounting for the big picture. These APIs are not like “map,”
“filter,” and “Dictionary.” They're specialty items that you should
only reach for when performing unsafe operations, mostly inside the guts
of higher-level constructs.

--
Dave

Would you like me to edit it and flip the proposal then? Put the MemoryLayout in as primary,
mine as secondary, and add in text to explain that the motivation is less usability than serving
an unsafe API with minimal surface area?

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[dabrahams (Dave Abrahams)]

Then feel free, of course! It's your choice, y'know. I wouldn't want
to ask you to propose something you don't believe in...

···

on Wed Jun 22 2016, Erica Sadun <swift-evolution@swift.org> wrote:

On Jun 21, 2016, at 7:07 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Tue Jun 21 2016, Erica Sadun <erica-AT-ericasadun.com <http://erica-at-ericasadun.com/&gt;&gt; wrote:

On Jun 21, 2016, at 6:06 PM, Dave Abrahams <dabrahams@apple.com> wrote:

It's just that I don't think this part of the library API is important
enough, to enough people, that this readability is worth the additional
exposed surface area (and further exposure later on—I can easily imagine
a “minimumAlignment”). I would *much* rather keep this stuff corralled
in a single namespace where it can all be found.

See? That, I totally get.

I think you represented it just fine, thanks... I just don't think
you're accounting for the big picture. These APIs are not like “map,”
“filter,” and “Dictionary.” They're specialty items that you should
only reach for when performing unsafe operations, mostly inside the guts
of higher-level constructs.

--
Dave

Would you like me to edit it and flip the proposal then? Put the
MemoryLayout in as primary, mine as secondary, and add in text to
explain that the motivation is less usability than serving an unsafe
API with minimal surface area?

Well, the review has already started, so I don't think we ought to go
inverting the proposal now. Let's see how the discussion plays out. If
at the end, you agree with my point-of-view, you can say so and the
review manager and core team will take that into account.

No, I'd do edits on a gist page not in-place

--
Dave