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

I believe the current approach needs improving. I am fine with both approaches.
You've more or less convinced me on a very good reason why a less perfect solution is
a better approach.

I just want to know if it would help going into the core team review to have that rationale
written up and formal in advance. If not, and this email back and forth is sufficient, I'm good.

-- E

···

On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

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

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

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...

I think it would. It would *really* help if someone would prepare a
patch that uses both APIs so we could see how the resulting code looks
in practice. :-)

···

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

On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

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

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

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...

I believe the current approach needs improving. I am fine with both
approaches. You've more or less convinced me on a very good reason
why a less perfect solution is a better approach.

I just want to know if it would help going into the core team review
to have that rationale written up and formal in advance.

--
Dave

Here you go: memorylayout.md · GitHub

-- E

···

On Jun 22, 2016, at 1:32 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

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

On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

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

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

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...

I believe the current approach needs improving. I am fine with both
approaches. You've more or less convinced me on a very good reason
why a less perfect solution is a better approach.

I just want to know if it would help going into the core team review
to have that rationale written up and formal in advance.

I think it would. It would *really* help if someone would prepare a
patch that uses both APIs so we could see how the resulting code looks
in practice. :-)

--
Dave

Thanks for the proposal, Erica. It contains some errors that I pointed
out in a comment on the Gist. Care to fix those?

···

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

On Jun 22, 2016, at 1:32 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:

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

On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution >>>> <swift-evolution@swift.org> wrote:

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

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

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...

I believe the current approach needs improving. I am fine with both
approaches. You've more or less convinced me on a very good reason
why a less perfect solution is a better approach.

I just want to know if it would help going into the core team review
to have that rationale written up and formal in advance.

I think it would. It would *really* help if someone would prepare a
patch that uses both APIs so we could see how the resulting code looks
in practice. :-)

--
Dave

Here you go:
memorylayout.md · GitHub
<https://gist.github.com/erica/57a64163870486468180b8bab8a6294e&gt;

--
Dave

public struct MemoryLayout<T> {
    public static var size: Int { return sizeof(T) }
    public static var interval: Int { return strideof(T) }
    public static var alignment: Int { return alignof(T) }
    
    init(_ : @autoclosure () -> T) {}
}

print(MemoryLayout<Int>.size) // 8
print(MemoryLayout<Int>.interval) // 8
print(MemoryLayout<Int>.alignment) // 8

let x = 8

print(MemoryLayout(x).dynamicType.size) // 8
print(MemoryLayout(x).dynamicType.interval) // 8
print(MemoryLayout(x).dynamicType.alignment) // 8

-- E

···

On Jun 28, 2016, at 12:11 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

I think it would. It would *really* help if someone would prepare a
patch that uses both APIs so we could see how the resulting code looks
in practice. :-)

--
Dave

Here you go:
memorylayout.md · GitHub
<https://gist.github.com/erica/57a64163870486468180b8bab8a6294e&gt;

Thanks for the proposal, Erica. It contains some errors that I pointed
out in a comment on the Gist. Care to fix those?

Isn't dynamicType possibly changing soon to a method?

This could look much different

Brandon

···

On Jun 28, 2016, at 4:53 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 28, 2016, at 12:11 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

I think it would. It would *really* help if someone would prepare a
patch that uses both APIs so we could see how the resulting code looks
in practice. :-)

--
Dave

Here you go:
memorylayout.md · GitHub
<https://gist.github.com/erica/57a64163870486468180b8bab8a6294e&gt;

Thanks for the proposal, Erica. It contains some errors that I pointed
out in a comment on the Gist. Care to fix those?

public struct MemoryLayout<T> {
    public static var size: Int { return sizeof(T) }
    public static var interval: Int { return strideof(T) }
    public static var alignment: Int { return alignof(T) }
    
    init(_ : @autoclosure () -> T) {}
}

print(MemoryLayout<Int>.size) // 8
print(MemoryLayout<Int>.interval) // 8
print(MemoryLayout<Int>.alignment) // 8

let x = 8

print(MemoryLayout(x).dynamicType.size) // 8
print(MemoryLayout(x).dynamicType.interval) // 8
print(MemoryLayout(x).dynamicType.alignment) // 8

-- E

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

Isn't dynamicType possibly changing soon to a method?

A free function, I think.

This could look much different

Yes, It will be uglier. But this very uncommon case is not important to
optimize for beauty.

···

on Tue Jun 28 2016, Brandon Knope <bknope-AT-me.com> wrote:

--
Dave

How about we get rid of dynamicType by adding instance level properties as well:

public struct MemoryLayout<T> {
    
    public static var size: Int { return sizeof(T) }
    public static var interval: Int { return strideof(T) }
    public static var alignment: Int { return alignof(T) }
    
    public var size: Int { return sizeof(T) }
    public var interval: Int { return strideof(T) }
    public var alignment: Int { return alignof(T) }
    
    init(_ : @autoclosure () -> T) {}
}

print(MemoryLayout<Int>.size) // 8
print(MemoryLayout<Int>.interval) // 8
print(MemoryLayout<Int>.alignment) // 8

let x = 8

print(MemoryLayout(x).size) // 8
print(MemoryLayout(x).interval) // 8
print(MemoryLayout(x).alignment) // 8

···

On Jun 28, 2016, at 5:08 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Tue Jun 28 2016, Brandon Knope <bknope-AT-me.com> wrote:

Isn't dynamicType possibly changing soon to a method?

A free function, I think.

This could look much different

Yes, It will be uglier. But this very uncommon case is not important to
optimize for beauty.

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

Reload memorylayout.md · GitHub and please make sure I properly updated the comments, the design, the examples.

-- E

···

On Jun 28, 2016, at 6:08 PM, Dave Abrahams <dabrahams@apple.com> wrote:
--
Dave

Just wanting to point out that option 2 could look vastly different! Neither looks "pretty", but the first one sure looks good :ok_hand:

Brandon

···

On Jun 28, 2016, at 8:08 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Tue Jun 28 2016, Brandon Knope <bknope-AT-me.com> wrote:

Isn't dynamicType possibly changing soon to a method?

A free function, I think.

This could look much different

Yes, It will be uglier. But this very uncommon case is not important to
optimize for beauty.

--
Dave

How about we get rid of dynamicType by adding instance level properties as well:

public struct MemoryLayout<T> {

    public static var size: Int { return sizeof(T) }
    public static var interval: Int { return strideof(T) }
    public static var alignment: Int { return alignof(T) }

    public var size: Int { return sizeof(T) }
    public var interval: Int { return strideof(T) }
    public var alignment: Int { return alignof(T) }

    init(_ : @autoclosure () -> T) {}
}

print(MemoryLayout<Int>.size) // 8
print(MemoryLayout<Int>.interval) // 8
print(MemoryLayout<Int>.alignment) // 8

let x = 8

print(MemoryLayout(x).size) // 8
print(MemoryLayout(x).interval) // 8
print(MemoryLayout(x).alignment) // 8

My worry is that people will write

  MemoryLayout(Int.self).size

when they mean

  MemoryLayout<Int>.size
     
(often because for some reason they don't like angle brackets).

I prefer to make the uncommon case much harder to write.

···

on Tue Jun 28 2016, Hooman Mehr <swift-evolution@swift.org> wrote:

On Jun 28, 2016, at 5:08 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:

on Tue Jun 28 2016, Brandon Knope <bknope-AT-me.com> wrote:

Isn't dynamicType possibly changing soon to a method?

A free function, I think.

This could look much different

Yes, It will be uglier. But this very uncommon case is not important to
optimize for beauty.

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

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

--
Dave

Would adding a "init(_: T.self) {...}" solve that issue?

- Dave Sweeris

···

Sent from my iPhone

On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

My worry is that people will write

MemoryLayout(Int.self).size

when they mean

MemoryLayout<Int>.size

(often because for some reason they don't like angle brackets).

I prefer to make the uncommon case much harder to write.

Would adding a "init(_: T.self) {...}" solve that issue?

? I don't see how.

···

on Wed Jun 29 2016, David Sweeris <davesweeris-AT-mac.com> wrote:

Sent from my iPhone

On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

My worry is that people will write

MemoryLayout(Int.self).size

when they mean

MemoryLayout<Int>.size

(often because for some reason they don't like angle brackets).

I prefer to make the uncommon case much harder to write.

--
Dave

(While I was typing this up, I realized that the exact usage you’re worried about, “MemoryLayout(Int.self).size” won’t compile, since `MemoryLayout` currently doesn’t have instance properties. If you’re worried about someone incorrectly typing out “MemoryLayout(Int.self).dynamicType.size”, though…)

I made a rather critical typo in my earlier reply. It should’ve been “init(_: T.Type)”, instead of “init(_: T.self)”, which is to say this:
extension MemoryLayout { // assuming `MemoryLayout<T>` is already defined as proposed
    public init(_ : T.Type) {} // makes it so that `MemoryLayout(T.self)` still has the correct type for `T`
}

Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
// without `init(_ : T.Type)` defined
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).dynamicType.size // 8, almost certainly wrong
//MemoryLayout(Int8).dynamicType.size // error
MemoryLayout(0 as Int8).dynamicType.size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly worded
//MemoryLayout(Int8.Type).dynamicType.size // error

// with `init(_ : T.Type)` defined
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).dynamicType.size // 1, almost certainly correct
MemoryLayout(Int8).dynamicType.size // 1, almost certainly correct
MemoryLayout(0 as Int8).dynamicType.size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly worded
MemoryLayout(Int8.Type).dynamicType.size // 8, correct

The only value that changes (aside from the errors) is the one “typo” that you were worried about.

Do this change your mind?

···

On Jun 29, 2016, at 12:34 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Wed Jun 29 2016, David Sweeris <davesweeris-AT-mac.com> wrote:

Would adding a "init(_: T.self) {...}" solve that issue?

? I don't see how.

Sent from my iPhone

On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

My worry is that people will write

MemoryLayout(Int.self).size

when they mean

MemoryLayout<Int>.size

(often because for some reason they don't like angle brackets).

I prefer to make the uncommon case much harder to write.

--
Dave

- Dave Sweeris

(While I was typing this up, I realized that the exact usage you’re
worried about, “MemoryLayout(Int.self).size” won’t compile, since
`MemoryLayout` currently doesn’t have instance properties. If you’re
worried about someone incorrectly typing out
“MemoryLayout(Int.self).dynamicType.size”, though…)

I made a rather critical typo in my earlier reply. It should’ve been
“init(_: T.Type)”, instead of “init(_: T.self)”, which is to say this:
extension MemoryLayout { // assuming `MemoryLayout<T>` is already defined
as proposed
    public init(_ : T.Type) {} // makes it so that `MemoryLayout(T.self)`
still has the correct type for `T`
}

Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
// without `init(_ : T.Type)` defined
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).dynamicType.size // 8, almost certainly wrong
//MemoryLayout(Int8).dynamicType.size // error
MemoryLayout(0 as Int8).dynamicType.size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly
worded
//MemoryLayout(Int8.Type).dynamicType.size // error

// with `init(_ : T.Type)` defined
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).dynamicType.size // 1, almost certainly
correct
MemoryLayout(Int8).dynamicType.size // 1, almost certainly
correct
MemoryLayout(0 as Int8).dynamicType.size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly
worded
MemoryLayout(Int8.Type).dynamicType.size // 8, correct

The only value that changes (aside from the errors) is the one “typo” that
you were worried about.

Do this change your mind?

These examples make no sense to me. Why are we asking for the size of the
dynamicType of MemoryLayout?

···

On Wed, Jun 29, 2016 at 4:29 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:

On Jun 29, 2016, at 12:34 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Wed Jun 29 2016, David Sweeris <davesweeris-AT-mac.com > <http://davesweeris-at-mac.com>> wrote:

Would adding a "init(_: T.self) {...}" solve that issue?

? I don't see how.

Sent from my iPhone

On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

My worry is that people will write

MemoryLayout(Int.self).size

when they mean

MemoryLayout<Int>.size

(often because for some reason they don't like angle brackets).

I prefer to make the uncommon case much harder to write.

--
Dave

- Dave Sweeris

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

No; it's too tricky. In your design MemoryLayout(x) now has two
different meanings depending on the type of x.

···

on Wed Jun 29 2016, David Sweeris <davesweeris-AT-mac.com> wrote:

(While I was typing this up, I realized that the exact usage you’re
worried about, “MemoryLayout(Int.self).size” won’t compile, since
`MemoryLayout` currently doesn’t have instance properties. If you’re
worried about someone incorrectly typing out
“MemoryLayout(Int.self).dynamicType.size”, though…)

I made a rather critical typo in my earlier reply. It should’ve been
“init(_: T.Type)”, instead of “init(_: T.self)”, which is to say this:
extension MemoryLayout { // assuming `MemoryLayout<T>` is already defined as proposed
    public init(_ : T.Type) {} // makes it so that `MemoryLayout(T.self)` still has the correct type for `T`
}

Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
// without `init(_ : T.Type)` defined
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).dynamicType.size // 8, almost certainly wrong
//MemoryLayout(Int8).dynamicType.size // error
MemoryLayout(0 as Int8).dynamicType.size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly worded
//MemoryLayout(Int8.Type).dynamicType.size // error

// with `init(_ : T.Type)` defined
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).dynamicType.size // 1, almost certainly correct
MemoryLayout(Int8).dynamicType.size // 1, almost certainly correct
MemoryLayout(0 as Int8).dynamicType.size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly worded
MemoryLayout(Int8.Type).dynamicType.size // 8, correct

The only value that changes (aside from the errors) is the one “typo” that you were worried about.

Do this change your mind?

--
Dave

That’s the “as proposed” usage for getting the size of a value (from https://gist.github.com/erica/57a64163870486468180b8bab8a6294e\)
// Types
MemoryLayout<Int>.size // 8
MemoryLayout<Int>.arraySpacing // 8
MemoryLayout<Int>.alignment // 8

// Value
let x: UInt8 = 5
MemoryLayout(x).dynamicType.size // 1
MemoryLayout("hello").dynamicType.arraySpacing // 24
MemoryLayout(29.2).dynamicType.alignment // 8

At least, I thought that was the latest version of the proposal. Maybe I’ve gotten confused.

- Dave Sweeris

···

On Jun 29, 2016, at 4:36 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Jun 29, 2016 at 4:29 PM, David Sweeris via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
(While I was typing this up, I realized that the exact usage you’re worried about, “MemoryLayout(Int.self).size” won’t compile, since `MemoryLayout` currently doesn’t have instance properties. If you’re worried about someone incorrectly typing out “MemoryLayout(Int.self).dynamicType.size”, though…)

I made a rather critical typo in my earlier reply. It should’ve been “init(_: T.Type)”, instead of “init(_: T.self)”, which is to say this:
extension MemoryLayout { // assuming `MemoryLayout<T>` is already defined as proposed
    public init(_ : T.Type) {} // makes it so that `MemoryLayout(T.self)` still has the correct type for `T`
}

Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
// without `init(_ : T.Type)` defined
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).dynamicType.size // 8, almost certainly wrong
//MemoryLayout(Int8).dynamicType.size // error
MemoryLayout(0 as Int8).dynamicType.size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly worded
//MemoryLayout(Int8.Type).dynamicType.size // error

// with `init(_ : T.Type)` defined
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).dynamicType.size // 1, almost certainly correct
MemoryLayout(Int8).dynamicType.size // 1, almost certainly correct
MemoryLayout(0 as Int8).dynamicType.size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is oddly worded
MemoryLayout(Int8.Type).dynamicType.size // 8, correct

The only value that changes (aside from the errors) is the one “typo” that you were worried about.

Do this change your mind?

These examples make no sense to me. Why are we asking for the size of the dynamicType of MemoryLayout?

On Jun 29, 2016, at 12:34 PM, Dave Abrahams <dabrahams@apple.com <mailto:dabrahams@apple.com>> wrote:

on Wed Jun 29 2016, David Sweeris <davesweeris-AT-mac.com <http://davesweeris-at-mac.com/&gt;&gt; wrote:

Would adding a "init(_: T.self) {...}" solve that issue?

? I don't see how.

Sent from my iPhone

On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

My worry is that people will write

MemoryLayout(Int.self).size

when they mean

MemoryLayout<Int>.size

(often because for some reason they don't like angle brackets).

I prefer to make the uncommon case much harder to write.

--
Dave

- Dave Sweeris

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

That’s the “as proposed” usage for getting the size of a value (from
https://gist.github.com/erica/57a64163870486468180b8bab8a6294e\)

// Types
MemoryLayout<Int>.size // 8
MemoryLayout<Int>.arraySpacing // 8
MemoryLayout<Int>.alignment // 8
// Valuelet x: UInt8 = 5
MemoryLayout(x).dynamicType.size // 1
MemoryLayout("hello").dynamicType.arraySpacing // 24
MemoryLayout(29.2).dynamicType.alignment // 8

At least, I *thought* that was the latest version of the proposal. Maybe
I’ve gotten confused.

There must be a typo in these examples. `MemoryLayout(x.dynamicType).size`
perhaps?

···

On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris@mac.com> wrote:

- Dave Sweeris

On Jun 29, 2016, at 4:36 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Wed, Jun 29, 2016 at 4:29 PM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:

(While I was typing this up, I realized that the exact usage you’re
worried about, “MemoryLayout(Int.self).size” won’t compile, since
`MemoryLayout` currently doesn’t have instance properties. If you’re
worried about someone incorrectly typing out
“MemoryLayout(Int.self).dynamicType.size”, though…)

I made a rather critical typo in my earlier reply. It should’ve been
“init(_: T.Type)”, instead of “init(_: T.self)”, which is to say this:
extension MemoryLayout { // assuming `MemoryLayout<T>` is already
defined as proposed
    public init(_ : T.Type) {} // makes it so that
`MemoryLayout(T.self)` still has the correct type for `T`
}

Here are the results of some quick playgrounding in the WWDC Xcode 8 beta:
// without `init(_ : T.Type)` defined
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).dynamicType.size // 8, almost certainly
wrong
//MemoryLayout(Int8).dynamicType.size // error
MemoryLayout(0 as Int8).dynamicType.size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is
oddly worded
//MemoryLayout(Int8.Type).dynamicType.size // error

// with `init(_ : T.Type)` defined
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).dynamicType.size // 1, almost certainly
correct
MemoryLayout(Int8).dynamicType.size // 1, almost certainly
correct
MemoryLayout(0 as Int8).dynamicType.size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).dynamicType.size // 8, correct, but is
oddly worded
MemoryLayout(Int8.Type).dynamicType.size // 8, correct

The only value that changes (aside from the errors) is the one “typo”
that you were worried about.

Do this change your mind?

These examples make no sense to me. Why are we asking for the size of the
dynamicType of MemoryLayout?

On Jun 29, 2016, at 12:34 PM, Dave Abrahams <dabrahams@apple.com> wrote:

on Wed Jun 29 2016, David Sweeris <davesweeris-AT-mac.com >> <http://davesweeris-at-mac.com/&gt;&gt; wrote:

Would adding a "init(_: T.self) {...}" solve that issue?

? I don't see how.

Sent from my iPhone

On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote:

My worry is that people will write

MemoryLayout(Int.self).size

when they mean

MemoryLayout<Int>.size

(often because for some reason they don't like angle brackets).

I prefer to make the uncommon case much harder to write.

--
Dave

- Dave Sweeris

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

There must be a typo in these examples. `MemoryLayout(x.dynamicType).size` perhaps?

Dunno if it’s intentional or not. Hooman Mehr already suggested we add instance properties:

How about we get rid of dynamicType by adding instance level properties as well:

public struct MemoryLayout<T> {
    
    public static var size: Int { return sizeof(T) }
    public static var interval: Int { return strideof(T) }
    public static var alignment: Int { return alignof(T) }
    
    public var size: Int { return sizeof(T) }
    public var interval: Int { return strideof(T) }
    public var alignment: Int { return alignof(T) }
    
    init(_ : @autoclosure () -> T) {}
}

print(MemoryLayout<Int>.size) // 8
print(MemoryLayout<Int>.interval) // 8
print(MemoryLayout<Int>.alignment) // 8

let x = 8

print(MemoryLayout(x).size) // 8
print(MemoryLayout(x).interval) // 8
print(MemoryLayout(x).alignment) // 8

Doing that makes that list look like this:
MemoryLayout<Int8>.size // 1, correct
MemoryLayout(Int8.self).size // 1, almost certainly correct
MemoryLayout(Int8).size // 1, almost certainly correct
MemoryLayout(0 as Int8).size // 1, correct
MemoryLayout<Int8.Type>.size // 8, correct
MemoryLayout(Int8.Type.self).size // 8, correct, but is oddly worded
MemoryLayout(Int8.Type).size // 8, correct

I thought of something else… if we had a way to intentionally trigger a compile-time error in code that’s otherwise correct, we could define the `init(_: T.self)` function like this:
extension MemoryLayout {
    public init(_ : T.Type) { #throwErrorIfReached("Incorrect Usage... NOCOMPILINGFORYOU!!!") }
}

Then the list of statements which compile would be much simpler:
let x: Int8 = 0
MemoryLayout<Int8>.size // 1, correct and unambiguous
MemoryLayout(x).size // 1, correct and unambiguous (assuming the instance properties are added)
MemoryLayout<Int8.Type>.size // 8, correct and unambiguous

But that’s its own proposal, and one I’m not sure is worth making.

- Dave Sweeris

···

On Jun 29, 2016, at 4:59 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Jun 28, 2016, at 8:27 PM, Hooman Mehr via swift-evolution <swift-evolution@swift.org> wrote:

I have listened. I have updated.

// Types
MemoryLayout<Int>.size // 8
MemoryLayout<Int>.arraySpacing // 8
MemoryLayout<Int>.alignment // 8

// Value
let x: UInt8 = 5
MemoryLayout.of(x).size // 1
MemoryLayout.of(1).size // 8
MemoryLayout.of("hello").arraySpacing // 24
MemoryLayout.of(29.2).alignment // 8

-- E

···

On Jun 29, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Wed, Jun 29, 2016 at 4:50 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:
That’s the “as proposed” usage for getting the size of a value (from https://gist.github.com/erica/57a64163870486468180b8bab8a6294e\)
// Types
MemoryLayout<Int>.size // 8
MemoryLayout<Int>.arraySpacing // 8
MemoryLayout<Int>.alignment // 8

// Value
let x: UInt8 = 5
MemoryLayout(x).dynamicType.size // 1
MemoryLayout("hello").dynamicType.arraySpacing // 24
MemoryLayout(29.2).dynamicType.alignment // 8

At least, I thought that was the latest version of the proposal. Maybe I’ve gotten confused.

There must be a typo in these examples. `MemoryLayout(x.dynamicType).size` perhaps?