The "UnsafeRawPointer Migration" guide talks about "binding memory to a type“
as if that was a well known term. I have never heard of it yet though, and
googling it returns no relevant results. I do not understand what binding
memory is supposed to do.
The migration guide says "Binding uninitia
Am 01.11.2016 um 21:40 schrieb Andrew Trick :
>
> I’m not sure I like the “prepares the memory” language myself. Binding memory
> communicates to the compiler that the memory locations are safe for typed
> access. Nothing happens at runtime--until someone writes a type safety
> sanitizer.
So n
Am 01.11.2016 um 21:43 schrieb Michael Ilseman :
>
> This is more so a semantic distinction rather than some kind of physical
> operation. The memory is not altered, but all reads and writes to that memory
> location have to be through the “bound type”. If it’s “bound” to some type T,
> you mus
> Am 02.11.2016 um 18:37 schrieb Rien :
>
>>>
>>> var rawPtr = UnsafeMutableRawPointer.allocate(bytes: 2, alignedTo: 0)
>>>
>>> var widePtr = rawPtr.bindMemory(to: Int16.self, capacity: 1)
>>>
>>> widePtr.pointee = 32
>>>
>>> var narrowPtr = rawPtr.bindMemory(to: UInt8.self, capacity: 2)
>>>
Am 03.11.2016 um 15:41 schrieb Rien :
>
> Ah, but that is not the case.
>
> It is important to differentiate between the “gateway” to the memory and the
> memory area itself.
> Different programming languages/compilers have different approaches, but I
> believe that Swift allocates a struct for
Why are names no longer Strings any more in Swift 4? I am all for type safety,
but now things like
NSImage(named: "Icon.png")
become
NSImage(named: NSImage.Name(rawValue: "Icon.png"))
and
NSWindowController(windowNibName: "Window")
becomes
NSWindowController(windowNibName: NSNib.Name(rawVal
> Am 17.07.2017 um 17:47 schrieb Joe Groff :
>
> Yeah, this is the intended use pattern for these namespaced constant. You
> don't need the `rawValue:` label, though:
>
> extension NSImage.Name {
> static let myImage = Name("myImage")
> }
It would be possible to do the same thing as an extens
> Am 17.07.2017 um 18:08 schrieb Jon Shier :
>
> Making them an extension on String makes them visible everywhere String is
> used, unless you limit the visibility in some way, which impacts the
> performance of autocomplete and fills it with random constants.
I see. Thanks for clarifying.
> Am 17.07.2017 um 18:12 schrieb Joe Groff :
>
> If you want to ensure that the string value corresponds to a declaration,
> maybe you could use #keyPath, which ought to be interchangeable with a string
> literal but checked by the compiler.
Excellent. Thanks a lot!
Manfred
_
> Am 18.07.2017 um 00:58 schrieb Greg Parker via swift-users
> :
>
>
>> On Jul 17, 2017, at 10:01 AM, Nevin Brackett-Rozinsky via swift-users
>> wrote:
>>
>> Could / should these types be ExpressibleByStringLiteral?
>
> They should not. We are deliberately discouraging the string literal of
How can I cast a path segment within #keyPath() ?
For example in the following code:
——
import Cocoa
class MyView: NSView {
var property: String?
}
class MyViewController: NSViewController {
var viewProperty: String? {
return (view as! MyView).property
> Am 25.07.2017 um 18:21 schrieb Charles Srstka :
>
> #keyPath(MyView.property) should do it, I’d think.
I think it wouldn't. It returns "property", but the path needs to be
"view.property".
Kind regards,
Manfred
___
swift-users mailing list
swift-
> Am 25.07.2017 um 18:31 schrieb Charles Srstka :
>
>> On Jul 25, 2017, at 11:26 AM, Manfred Schubert wrote:
>>
>>
>>> Am 25.07.2017 um 18:21 schrieb Charles Srstka :
>>>
>>> #keyPath(MyView.property) should do it, I’d think.
>>
>> I think it wouldn't. It returns "property", but the path nee
13 matches
Mail list logo
