Thanks! Missed that.

I think it would be OK if the transparent bridging called cString(using:) 
itself, and the whole thing would fail if the conversion fails.

-Kenny


> On Jun 22, 2016, at 11:52 AM, Ben Rimmington <[email protected]> wrote:
> 
> 
>> On 22 Jun 2016, at 17:37, Kenny Leung via swift-evolution 
>> <[email protected]> wrote:
>> 
>> What does surprise me is that Swift String bridges directly into “char *” 
>> arguments in C as nul-terminated C strings, apparently preserving unicode 
>> and all. I can find nothing on bridging to “char *” in “Using Swift with 
>> Cocoa and Objective-C"
> 
> * Using Swift with Cocoa and Objective-C > Interoperability > Interacting 
> with C APIs > Pointers > Constant Pointers:
> 
> "When a function is declared as taking a UnsafePointer<Type> argument, it can 
> accept [...] A String value, if Type is Int8 or UInt8. The string will 
> automatically be converted to UTF8 in a buffer, and a pointer to that buffer 
> is passed to the function."
> 
>> In the spirit of preventing you from hurting yourself, I think this 
>> functionality should be removed, forcing you to use cString(using:) first.
> 
> Do you mean the encoding should always be given, instead of using UTF-8 by 
> default? I think the no-argument -[NSString cString] method was deprecated 
> for this reason?
> 
> -- Ben

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to