<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I hit a related problem here:</div><div class=""><br class=""></div><div class=""><a href="https://github.com/bustoutsolutions/siesta/blob/master/Source/Resource.swift#L427" class="">https://github.com/bustoutsolutions/siesta/blob/master/Source/Resource.swift#L427</a></div><div class=""><br class=""></div><div class="">I know I have an ASCII-only string because I’ve just applied escaping, but still have to force-unwrap the result of dataUsingEncoding(NSASCIIStringEncoding). Annoying!</div><div class=""><br class=""></div><div class="">However, I’m not sure that a new type would be a good way to solve this. A string may have many attributes that make it suitable or unsuitable for use in different situations: single line, valid identifier in a given language, no surrogate chars, no spaces … plus, of course, “valid in encoding X” for every encoding.</div><div class=""><br class=""></div><div class="">Handling these cases via the type system would result in a combinatorial explosion of API methods like dataUsingEncoding.</div><div class=""><br class=""></div><div class="">IMO, this is a perfect example of where force unwrapping is the right tool: I’m able to make guarantees about the correctness of the code that the compiler can’t verify. I’m OK with that.</div><div class=""><br class=""></div><div class="">• • •</div><div class=""><br class=""></div><div class="">If there’s a compelling use case for ASCIIString, it’s performance. In that case, I wonder whether:</div><div class=""><br class=""></div><div class="">• perhaps this would better be implemented as a set of extension methods on [<span style="font-family: HelveticaNeue;" class="">UInt8</span>] that do string-like things, instead of being a separate type, and</div><div class=""><br class=""></div><div class="">• perhaps String could — or already does — provide internal optimizations when the string is internally representable as single-byte chars.</div><div class=""><br class=""></div><div class="">Cheers, P</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 13, 2015, at 3:47 PM, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">StaticString provides an "isASCII" boolean property, but manipulating strings still requires the use of UnicodeScalarView / CharacterView, even if the strings are statically known to be ASCII-only.<div class=""><br class=""></div><div class="">I think it would be nice to have an ASCIIString in the standard library, similar to StaticString but with the following improvements:</div><div class=""><br class=""></div><div class="">- ASCIIString itself would be MutableCollectionType, with Index == Int for easy access.</div><div class=""><br class=""></div><div class="">- Its Generator.Element would be something which works with simple + and - operators (either UInt8, or perhaps a repurposed UnicodeScalar, or a new ASCIIScalar).</div><div class=""><br class=""></div><div class="">- The ability to create new ASCIIStrings at runtime, by appending/removing bytes, or by concatenating other ASCIIStrings.</div><div class=""><br class=""></div><div class="">Would anyone else find this useful?</div><div class=""><div class=""><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class="">Jacob Bandes-Storch<br class=""></div></div></div></div>
</div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=zCg-2FSGF9Wk188a6c55kLyEbrj7YhaXxFEHM-2F-2B0YAlzUGML8V3ZrVQOoryx2tl2tEr60bXG6n3HFBW8TLcCR0r9zbCuzCB6OOs59DrlPW56x5mYcC9pcaBiQcxLKb-2BNwulxy4eVQ-2FP7fRuLtrTkJ01dUUC8X9Ry9LfhKT-2FTyVAMQEy-2BU-2BMpNfWOUXhwCo8GipaGB6UMvvKbXNILKymTb65t-2FPjWrujxc2akf3heO-2Fux0-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>