Hello all,
I was wondering what an exclamation mark in a swift parameter listing
means. For instance, I used Elements Oxidizer Live to translate some
C# code into Swift. Reviewing it, I found the following (among
others): @DllImport("ScriptHookV.dll")
private static __extern func scriptRegister(_ module: System.IntPtr!,
_ LP_SCRIPT_MAIN: LP_SCRIPT_MAINDelegate!)
What I'm wondering is what does the '!' in that list of parameters
mean? I also saw it when writing another program:
func MainForm_Load(_ sender: System.Object!, _ e: System.EventArgs!) {
// ...
}
I don't recall the swift book teaching you what that means, so could
someone tell me what those mean?
On Jan 9, 2017, at 4:23 PM, Ethin Probst via swift-users <swift-users@swift.org> wrote:
Hello all,
I was wondering what an exclamation mark in a swift parameter listing
means. For instance, I used Elements Oxidizer Live to translate some
C# code into Swift. Reviewing it, I found the following (among
others): @DllImport("ScriptHookV.dll")
private static __extern func scriptRegister(_ module: System.IntPtr!,
_ LP_SCRIPT_MAIN: LP_SCRIPT_MAINDelegate!)
What I'm wondering is what does the '!' in that list of parameters
mean? I also saw it when writing another program:
func MainForm_Load(_ sender: System.Object!, _ e: System.EventArgs!) {
// ...
}
I don't recall the swift book teaching you what that means, so could
someone tell me what those mean?
--
Signed,
Ethin D. Probst
_______________________________________________
swift-users mailing list
swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
It means that a call to that function with an optional will unwrap the optional before it is used.
That is quite neat when dealing with C-API’s because often you will receive a pointer from a C-function which is optional to account for the fact that it can be NULL (= nil).
By using a forced unwrapped input parameter you are saved the trouble of unwrapping all these pointers when using them as input for other C-APIs.
In short, it makes it easier to interface with C-API’s.
Note that there is some under-the-hood magic going on because a C-pointer is an unboxed value, while a ‘normal’ optional is a boxed value.
On 10 Jan 2017, at 01:23, Ethin Probst via swift-users <swift-users@swift.org> wrote:
Hello all,
I was wondering what an exclamation mark in a swift parameter listing
means. For instance, I used Elements Oxidizer Live to translate some
C# code into Swift. Reviewing it, I found the following (among
others): @DllImport("ScriptHookV.dll")
private static __extern func scriptRegister(_ module: System.IntPtr!,
_ LP_SCRIPT_MAIN: LP_SCRIPT_MAINDelegate!)
What I'm wondering is what does the '!' in that list of parameters
mean? I also saw it when writing another program:
func MainForm_Load(_ sender: System.Object!, _ e: System.EventArgs!) {
// ...
}
I don't recall the swift book teaching you what that means, so could
someone tell me what those mean?
--
Signed,
Ethin D. Probst
_______________________________________________
swift-users mailing list
swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
On Jan 9, 2017, at 11:19 PM, Rien via swift-users <swift-users@swift.org> wrote:
It means that a call to that function with an optional will unwrap the optional before it is used.
That is quite neat when dealing with C-API’s because often you will receive a pointer from a C-function which is optional to account for the fact that it can be NULL (= nil).
By using a forced unwrapped input parameter you are saved the trouble of unwrapping all these pointers when using them as input for other C-APIs.
In short, it makes it easier to interface with C-API’s.
Note that there is some under-the-hood magic going on because a C-pointer is an unboxed value, while a ‘normal’ optional is a boxed value.
I do/did think that there is a difference in the way it handles pointers optionals and other optionals, but I now realise that even that could not be the case.
So please ignore the last line in my previous post.
On 10 Jan 2017, at 18:14, Joe Groff <jgroff@apple.com> wrote:
On Jan 9, 2017, at 11:19 PM, Rien via swift-users <swift-users@swift.org> wrote:
It means that a call to that function with an optional will unwrap the optional before it is used.
That is quite neat when dealing with C-API’s because often you will receive a pointer from a C-function which is optional to account for the fact that it can be NULL (= nil).
By using a forced unwrapped input parameter you are saved the trouble of unwrapping all these pointers when using them as input for other C-APIs.
In short, it makes it easier to interface with C-API’s.
Note that there is some under-the-hood magic going on because a C-pointer is an unboxed value, while a ‘normal’ optional is a boxed value.
For what it’s worth, if T is a reference type or Unsafe*Pointer, then T and Optional<T> have the same exact representation in memory.
The compiler is smart enough to know that a non-optional pointer can never be NULL, so a NULL value of the underlying type can be used to unambiguously encode the ‘none’ case. This is not the case with Optional<NSRect> for example, where every bit pattern represents a potentially valid NSRect value, so Optional<NSRect> has to add an extra tag byte to distinguish the two enum cases from each other.
Slava
···
On Jan 10, 2017, at 9:52 AM, Rien via swift-users <swift-users@swift.org> wrote:
I stand corrected.
I do/did think that there is a difference in the way it handles pointers optionals and other optionals, but I now realise that even that could not be the case.
So please ignore the last line in my previous post.
On 10 Jan 2017, at 18:14, Joe Groff <jgroff@apple.com> wrote:
On Jan 9, 2017, at 11:19 PM, Rien via swift-users <swift-users@swift.org> wrote:
It means that a call to that function with an optional will unwrap the optional before it is used.
That is quite neat when dealing with C-API’s because often you will receive a pointer from a C-function which is optional to account for the fact that it can be NULL (= nil).
By using a forced unwrapped input parameter you are saved the trouble of unwrapping all these pointers when using them as input for other C-APIs.
In short, it makes it easier to interface with C-API’s.
Note that there is some under-the-hood magic going on because a C-pointer is an unboxed value, while a ‘normal’ optional is a boxed value.
On 19 Jan 2017, at 05:57, Slava Pestov <spestov@apple.com> wrote:
For what it’s worth, if T is a reference type or Unsafe*Pointer, then T and Optional<T> have the same exact representation in memory.
The compiler is smart enough to know that a non-optional pointer can never be NULL, so a NULL value of the underlying type can be used to unambiguously encode the ‘none’ case. This is not the case with Optional<NSRect> for example, where every bit pattern represents a potentially valid NSRect value, so Optional<NSRect> has to add an extra tag byte to distinguish the two enum cases from each other.
Slava
On Jan 10, 2017, at 9:52 AM, Rien via swift-users <swift-users@swift.org> wrote:
I stand corrected.
I do/did think that there is a difference in the way it handles pointers optionals and other optionals, but I now realise that even that could not be the case.
So please ignore the last line in my previous post.
On 10 Jan 2017, at 18:14, Joe Groff <jgroff@apple.com> wrote:
On Jan 9, 2017, at 11:19 PM, Rien via swift-users <swift-users@swift.org> wrote:
It means that a call to that function with an optional will unwrap the optional before it is used.
That is quite neat when dealing with C-API’s because often you will receive a pointer from a C-function which is optional to account for the fact that it can be NULL (= nil).
By using a forced unwrapped input parameter you are saved the trouble of unwrapping all these pointers when using them as input for other C-APIs.
In short, it makes it easier to interface with C-API’s.
Note that there is some under-the-hood magic going on because a C-pointer is an unboxed value, while a ‘normal’ optional is a boxed value.
Boxing usually refers to out-of-line allocation of values on the heap. For example, values of protocol type (as well as Any) will box their payload, depending on size.
Slava
···
On Jan 18, 2017, at 10:53 PM, Rien <Rien@Balancingrock.nl> wrote:
Thanks Slava,
Then my memory wasn’t that bad. This is indeed what I was thinking of, but I should not have referred to it as ‘boxing’ ?
On 19 Jan 2017, at 05:57, Slava Pestov <spestov@apple.com> wrote:
For what it’s worth, if T is a reference type or Unsafe*Pointer, then T and Optional<T> have the same exact representation in memory.
The compiler is smart enough to know that a non-optional pointer can never be NULL, so a NULL value of the underlying type can be used to unambiguously encode the ‘none’ case. This is not the case with Optional<NSRect> for example, where every bit pattern represents a potentially valid NSRect value, so Optional<NSRect> has to add an extra tag byte to distinguish the two enum cases from each other.
Slava
On Jan 10, 2017, at 9:52 AM, Rien via swift-users <swift-users@swift.org> wrote:
I stand corrected.
I do/did think that there is a difference in the way it handles pointers optionals and other optionals, but I now realise that even that could not be the case.
So please ignore the last line in my previous post.
On 10 Jan 2017, at 18:14, Joe Groff <jgroff@apple.com> wrote:
On Jan 9, 2017, at 11:19 PM, Rien via swift-users <swift-users@swift.org> wrote:
It means that a call to that function with an optional will unwrap the optional before it is used.
That is quite neat when dealing with C-API’s because often you will receive a pointer from a C-function which is optional to account for the fact that it can be NULL (= nil).
By using a forced unwrapped input parameter you are saved the trouble of unwrapping all these pointers when using them as input for other C-APIs.
In short, it makes it easier to interface with C-API’s.
Note that there is some under-the-hood magic going on because a C-pointer is an unboxed value, while a ‘normal’ optional is a boxed value.