Re: [swift-evolution] Reduce with inout

[Charles Srstka via swift-evolution]

> On Jan 21, 2017, at 12:37 AM, Russ Bishop  wrote:
> 
>> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution 
>> > wrote:
> 
>> I don’t even know how long it actually takes to finish this test, because 
>> the last time I did this I eventually got sick of waiting and killed the 
>> process. So, I don’t know quite how many orders of magnitude slower it is, 
>> but it’s a lot.
> 
> That’s all the endorsement I need. +1 from me.
> 
> 
> I do wonder if there is any way to get this sort of optimization out of the 
> compiler. I suppose it would be difficult because the compiler doesn’t know 
> what the mutable vs immutable pairs are or if such a pair even exists (array 
> doesn’t have appending()).

The (somewhat naïve) assumption that some optimization of this sort might be 
going on is what led me to do the speed test in the first place. However, when 
you think about it, it’d be really quite hard to do. A reduce that builds an 
array consists of the closure that adds something to an array, and the reduce 
function itself. With the code to both of these, it’s not inconceivable that 
the compiler could figure out what you’re doing, but unfortunately the two 
components live in different modules / compilation units. The closure doesn’t 
know that its return value is just going to be replacing the passed-in value, 
and the reduce function doesn’t know that the closure isn’t going to store the 
original array somewhere, so neither can really know that it’s safe to modify 
the array in place.

Charles

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

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

[Karl Wagner via swift-evolution]

This is very interesting and all Swift developers will need to be aware of it, 
if it isn’t a bug.

One thing that I think is a little worrying is that if, rather than the == 
operator, you had a CustomEquatable protocol which defined the equal(to:) 
function, that function would be dynamically dispatched. You would think that 
operator witnesses should be resolved in the same way.

I believe that should even work for the dynamic Self; we have already verified 
at compile-time that an overload exists (even though it may not be the most 
appropriate one to execute). So you would get:

let a = Sub()
let b = Sub()
let c = Super()

(a as Super) == b // Both values have (dynamic) type Sub, calls ==(Sub,Sub)
a == c   // One type is not a Sub, must compare using ==(Super, 
Super)

- Krl

> On 20 Jan 2017, at 20:24, Pierre Monod-Broca via swift-evolution 
>  wrote:
> 
> The way I understand it, it's a bad idea to override == and != (or any infix 
> operator) for Sub if Super has them and that's why the default implementation 
> from Equatable only generates !=(Super, Super) and not !=(Sub, Sub) (and 
> there is no ==(Sub, Sub) generated either).
> 
> And it's a bad idea because (without dynamic dispatch on both operands) it 
> leads to unexpected behavior.
> 
> Considering :
> ```
> func ==(lhs: Super, rhs: Super) -> Bool {
> print("Super")
> return true
> }
> 
> func ==(lhs: Sub, rhs: Sub) -> Bool {
> print("Sub")
> return false
> }
> 
> let a = Sub()
> let b = Sub()
> a == b // Sub
> a as Super == b // Super
> a == b as Super // Super
> à as Super == b as Super // Super
> ```
> 
> One would compare the same objects and don't get the same result.
> 
> Instead you have to check the dynamic type yourself.
> 
> 
> Pierre
> 
> Le 20 janv. 2017 à 10:45, Francisco Javier Fernández Toro via swift-evolution 
> > a écrit :
> 
>> 
>> 
>> On Wed, Jan 18, 2017 at 6:58 PM, Tony Allevato > > wrote:
>> Ok, this actually does feel a bit strange. The behavior you're seeing seems 
>> to be a consequence of 
>> [SE-0091](https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md
>>  
>> ),
>>  but it looks like you're seeing different behavior than what I described in 
>> the "Class types and inheritance" section of that proposal.
>> 
>> If Sub has `==(Sub, Sub)` implemented as a *static* function, I just tried 
>> it and it's *ignored* (`==(Super, Super)` gets called instead), even when 
>> the two actual arguments are known to be statically of type Sub. I think 
>> this is because of the way that proposal was implemented: when it sees that 
>> `Sub` extends `Super`, which conforms to `Equatable`, it appears that it's 
>> only looking for static overloads of `==` that are satisfied at the *point 
>> of conformance*, which would be `==(Super, Super)` (because `Super` conforms 
>> to `Equatable where Self == Super`). The wording of the proposal makes this 
>> case: "Then, we say that we do not consider an operator function if it 
>> implements a protocol requirement, because the requirement is a 
>> generalization of all of the operator functions that satisfy that 
>> requirement."
>> 
>> Contrarily, if you provide `==(Sub, Sub)` as a global function instead of a 
>> static one, it *does* get called. I think in this case, the type checker 
>> gets the whole set of candidate operators (which, unlike above, includes the 
>> global `==(Sub, Sub)`), and it gets used because it's a more specific match?
>> 
>> 
>> FWIW, I've just changed both `==` functions to make them global, the the 
>> outcome is still the same, its using `==(Super,Super)` to resolve 
>> `!=(Sub,Sub)
>>  
>> Can someone from the core team chime in and say whether this is intentional 
>> behavior? It feels wrong that simply changing the location where the 
>> operator is defined would change the behavior like this.
>> 
>> FWIW, to avoid these sharp edges, there's no need to implement `==` for 
>> subtypes; since you have to use an overridable `equals` method anyway, just 
>> have the base type implement `==` to delegate to it, and then have subtypes 
>> override `equals` alone.
>> 
>> 
>> On Wed, Jan 18, 2017 at 9:36 AM Francisco Javier Fernández Toro 
>> > wrote:
>> Yeah guys, you are right, my code is busted, I was trying to point something 
>> different out:
>> 
>> The next code is showing the possible issue. In theory to make a class 
>> Equatable, you just have to mark it with the Equatable protocol and 
>> implement `==` as a static function or as a global one.
>> 
>> If you don't override the equal method and you just invoke your super class 
>> equality method you'll get something like this: 

Re: [swift-evolution] Reduce with inout

[Georgios Moschovitis via swift-evolution]

> 
>> On 18 Jan 2017, at 12:45, Georgios Moschovitis 
>>  wrote:
>> 
>>> That’s what I thought also until just now, but then why wouldn’t you just 
>>> use a for …  in loop?
>> 
>> the former gives a hint about what someFunction (and the for-loop) is doing.
> 
> 
> Whereas the latter explicitly lays out what is happening.

But, you have to actually read the loop to understand that it *is* reducing.
In this simple case, it’s obvious, but for more complex reduction, the ‘hint’ 
can be useful.

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

Re: [swift-evolution] Reduce with inout

[Russ Bishop via swift-evolution]

> On Jan 16, 2017, at 9:43 AM, Charles Srstka via swift-evolution 
>  wrote:

> I don’t even know how long it actually takes to finish this test, because the 
> last time I did this I eventually got sick of waiting and killed the process. 
> So, I don’t know quite how many orders of magnitude slower it is, but it’s a 
> lot.

That’s all the endorsement I need. +1 from me.


I do wonder if there is any way to get this sort of optimization out of the 
compiler. I suppose it would be difficult because the compiler doesn’t know 
what the mutable vs immutable pairs are or if such a pair even exists (array 
doesn’t have appending()).

If we assume + for Array had a mutating variant ala func + (lhs: inout Array, 
rhs: Array) { … }, would the compiler be able to prefer the inout version? What 
if a type wanted to offer a specialized version of a function for the compiler 
to call when the compiler can prove only temporaries are involved? I don’t want 
to go too far down the road of move constructors and whatnot for that way lies 
madness.


(Not a compiler expert, just wondering if there is a way to make situations 
like this into a “pit of success”).

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

Re: [swift-evolution] Assigning to 'self' in protocol extensions

[Russ Bishop via swift-evolution]

> On Jan 19, 2017, at 11:11 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Jan 19, 2017, at 10:52 PM, rintaro ishizaki via swift-evolution 
>> > wrote:
>> 
>> From the perspective of the caller, I think, this behavior is 
>> counterintuitive because we use "reference types" with an expectation: the 
>> referencing address would never be changed unless we explicitly replace the 
>> object by re-assigning to the variable in call sites, e.g.,
>> 
>> 
> 
> Well, there’s no real difficulty here, other than potential user confusion. 
> The ‘self’ parameter for a mutating method is passed inout, so this behaves 
> as if you called a global function with an inout argument. The difference is 
> of course when you pass a non-self inout argument, the compiler requires you 
> to use the explicit & syntax at the call site.
> 
> Is your proposal to ban calls to such mutating methods on a type that is 
> known to be a reference type at compile time altogether? This will create an 
> inconsistency between code that operates on concrete types and code that 
> operates on generic parameters (in the latter case the compiler of course has 
> no way to statically guarantee that the value is not a reference type).
> 
> The last time this quirk came up in internal discussions, the thought some of 
> us had was that it might be worthwhile to prohibit classes from conforming to 
> protocols with mutating requirements altogether. If you think about it, this 
> makes some amount of sense — it seems like it would be quite hard to write 
> code that can operate on both mutable values and mutable references 
> generically, since the latter do not have value semantics:

Right now you could consider mutable vs non-mutable functions as “advisory” for 
reference types since it is up to you to fulfill that contract.  

I suppose you could say that reference type members can’t do any stores to self 
unless the function is decorated in some way to advise the compiler that the 
mutation is intended but that’s a big change and not terribly useful. It would 
still be on the programmer to use the special decoration only in appropriate 
places that obey the mutability invariant (think a LRU cache doing a read() 
where mutation is not observable by the caller).

The alternate world where I can’t have value and reference types conform to the 
same protocol if the protocol has any mutating methods is a bit stifling.


IMHO in this case the consistency is more important than the quirk. 


Russ

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

Re: [swift-evolution] Strings in Swift 4

[Brent Royal-Gordon via swift-evolution]

> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> on Fri Jan 20 2017, Joe Groff  wrote:
> 
>> Jordan points out that the generalized slicing syntax stomps on '...x'
>> and 'x...', which would be somewhat obvious candidates for variadic
>> splatting if that ever becomes a thing. Now, variadics are a much more
>> esoteric feature and slicing is much more important to day-to-day
>> programming, so this isn't the end of the world IMO, but it is
>> something we'd be giving up.
> 
> Good point, Jordan.

In my experiments with introducing one-sided operators in Swift 3, I was not 
able to find a case where you actually wanted to write `c[i...]`. Everything I 
tried needed to use `c[i..<]` instead. My conclusion was that there was no 
possible use for postfix `...`; after all, `c[i...]` means `c[i...c.endIndex]`, 
which means `c[i..

Re: [swift-evolution] Strings in Swift 4

[Jordan Rose via swift-evolution]

I want to start by saying great work, Ben and Dave. I know you've put a lot of time into this (and humored me in several Apple-internal discussions) and what's here looks like a great overhaul of String, balancing several tricky constraints. I do want to record some comments on specific parts of the proposal that I still have concerns about, but as usual you can of course take these with a grain of salt.To ease the pain of type mismatches, Substring should be a subtype of String in the same way that Int is a subtype of Optional. This would give users an implicit conversion from Substring to String, as well as the usual implicit conversions such as [Substring] to [String] that other subtype relationships receive.I'm concerned about this for two reasons: first, because even with the comparison with Optional boxing, this is basically adding arbitrary conversions to the language, which we took out in part because of their disastrous effect on the performance of the type checker; and second, because this one in particular makes an O(N) copy operation very subtle (though admittedly one you incur all the time today, with no opt-out). A possible mitigation for the first issue would be to restrict the implicit conversion to arguments, like we do for inout-to-pointer conversions. It's still putting implicit conversions back into the language, though.Therefore, APIs that operate on an NSString/NSRange pair should be imported without the NSRange argument. The Objective-C importer should be changed to give these APIs special treatment so that when a Substring is passed, instead of being converted to a String, the full NSString and range are passed to the Objective-C method, thereby avoiding a copy.I'm very skeptical about assuming that a method that takes an NSString and an NSRange automatically means to apply that NSRange to the NSString, but fortunately it may not be much of an issue in practice. A quick grep of Foundation and AppKit turned up only 45 methods that took both an NSRange and an NSString *, clustered on a small number of classes; in less than half of these cases would the transformation to Substring actually be valid (the other ranges refer to some data in the receiver rather than the argument). I've attached these results below, if you're interested.(Note that I left out methods on NSString itself, since those are manually bridged to String, but there aren't actually too many of those either. "Foundation and AppKit" also isn't exhaustive, of course.)-Foundation.framework/Headers/NSAttributedString.h:- 
(void)replaceCharactersInRange:(NSRange)range withString:(NSString *)str;
-Foundation.framework/Headers/NSAttributedString.h:- (nullable 
id)attribute:(NSString *)attrName atIndex:(NSUInteger)location 
longestEffectiveRange:(nullable NSRangePointer)range 
inRange:(NSRange)rangeLimit;
-Foundation.framework/Headers/NSAttributedString.h:- 
(void)enumerateAttribute:(NSString *)attrName inRange:(NSRange)enumerationRange 
options:(NSAttributedStringEnumerationOptions)opts usingBlock:(void 
(NS_NOESCAPE ^)(id _Nullable value, NSRange range, BOOL *stop))block 
NS_AVAILABLE(10_6, 4_0);
-Foundation.framework/Headers/NSAttributedString.h:- 
(void)addAttribute:(NSString *)name value:(id)value range:(NSRange)range;
-Foundation.framework/Headers/NSAttributedString.h:- 
(void)removeAttribute:(NSString *)name range:(NSRange)range;
+Foundation.framework/Headers/NSFormatter.h:- 
(BOOL)isPartialStringValid:(NSString * _Nonnull * _Nonnull)partialStringPtr 
proposedSelectedRange:(nullable NSRangePointer)proposedSelRangePtr 
originalString:(NSString *)origString 
originalSelectedRange:(NSRange)origSelRange errorDescription:(NSString * 
_Nullable * _Nullable)error;
-Foundation.framework/Headers/NSLinguisticTagger.h:- 
(void)enumerateTagsInRange:(NSRange)range scheme:(NSString *)tagScheme 
options:(NSLinguisticTaggerOptions)opts usingBlock:(void (NS_NOESCAPE 
^)(NSString *tag, NSRange tokenRange, NSRange sentenceRange, BOOL *stop))block 
NS_AVAILABLE(10_7, 5_0);
-Foundation.framework/Headers/NSLinguisticTagger.h:- (NSArray 
*)tagsInRange:(NSRange)range scheme:(NSString *)tagScheme 
options:(NSLinguisticTaggerOptions)opts tokenRanges:(NSArray * 
_Nullable * _Nullable)tokenRanges NS_AVAILABLE(10_7, 5_0);
-Foundation.framework/Headers/NSLinguisticTagger.h:- (NSArray 
*)linguisticTagsInRange:(NSRange)range scheme:(NSString *)tagScheme 
options:(NSLinguisticTaggerOptions)opts orthography:(nullable NSOrthography 
*)orthography tokenRanges:(NSArray * _Nullable * 
_Nullable)tokenRanges NS_AVAILABLE(10_7, 5_0);
-Foundation.framework/Headers/NSLinguisticTagger.h:- 
(void)enumerateLinguisticTagsInRange:(NSRange)range scheme:(NSString 
*)tagScheme options:(NSLinguisticTaggerOptions)opts orthography:(nullable 
NSOrthography *)orthography usingBlock:(void (NS_NOESCAPE ^)(NSString *tag, 
NSRange tokenRange, NSRange sentenceRange, BOOL *stop))block NS_AVAILABLE(10_7, 
5_0);
+Foundation.framework/Headers/NSRegularExpression.h:- 

Re: [swift-evolution] Strings in Swift 4

[Ben Cohen via swift-evolution]

> On Jan 20, 2017, at 2:58 PM, Saagar Jha via swift-evolution 
>  wrote:
> 
> Sorry if I wasn’t clear; I’m looking for indexing using Int, instead of using 
> formIndex.


Question: why do you think integer indices are so desirable?

Integer indexing is simple, but also encourages anti-patterns (tortured 
open-coded while loops with unexpected fencepost errors, conflation of 
positions and distances into a single type) and our goal should be to make most 
everyday higher-level operations, such as finding/tokenizing, so easy that 
Swift programmers don’t feel they need to resort to loops as often.

Examples where formIndex is so common yet so cumbersome that it would be worth 
efforts to create integer-indexed versions of string might be indicators of 
important missing features on our collection or string APIs. So do pass them 
along.

(There are definitely known gaps in them today – slicing needs improving as the 
manifesto mentions for things like slices from an index to n elements later. 
Also, we need support for in-place remove(where:) operations. But the more 
commonly needed cases we know about that aren’t covered, the better)


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

Re: [swift-evolution] Strings in Swift 4

[Joe Groff via swift-evolution]

> On Jan 20, 2017, at 5:15 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Jan 20, 2017, at 3:29 PM, Jaden Geller via swift-evolution 
>>  wrote:
>> 
>> Wouldn’t `x[…]` be more consistent with these other syntaxes?
>> 
> 
> Maybe (though are those extra characters really telling you much?). 
> 
> But you can’t write that in Swift – you’d need a 0-argument operator.
> 
> (Or a […] postfix operator I guess if you wanted to try and sneak that 
> through, but that is also not allowed…  :)

Technically, you can, since operators are function values:

struct Foo {}
struct Woo { subscript(_: (Foo, Foo) -> Foo) -> Int { return 0 } }
func ...(_ x: Foo, _ y: Foo) -> Foo { return x }

Woo()[...]

Whether you *want* to, though…

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

Re: [swift-evolution] Strings in Swift 4

[Ben Cohen via swift-evolution]

> On Jan 20, 2017, at 6:11 PM, Joe Groff  wrote:
> 
> 
>> On Jan 20, 2017, at 5:15 PM, Ben Cohen via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Jan 20, 2017, at 3:29 PM, Jaden Geller via swift-evolution 
>>> > wrote:
>>> 
>>> Wouldn’t `x[…]` be more consistent with these other syntaxes?
>>> 
>> 
>> Maybe (though are those extra characters really telling you much?). 
>> 
>> But you can’t write that in Swift – you’d need a 0-argument operator.
>> 
>> (Or a […] postfix operator I guess if you wanted to try and sneak that 
>> through, but that is also not allowed…  :)
> 
> Technically, you can, since operators are function values:
> 
> struct Foo {}
> struct Woo { subscript(_: (Foo, Foo) -> Foo) -> Int { return 0 } }
> func ...(_ x: Foo, _ y: Foo) -> Foo { return x }
> 
> Woo()[...]
> 
> Whether you *want* to, though…
> 
> -Joe


I stand corrected, this totally works! Ship it...

extension String: Collection { }
extension Collection {
subscript(_: (Self,Self)->Void) -> SubSequence {
return self[startIndex..

Re: [swift-evolution] Compiler Optimization of Optional-returning Functions followed by '!'

[Karl Wagner via swift-evolution]

> On 20 Jan 2017, at 07:41, Russ Bishop via swift-evolution 
>  wrote:
> 
> 
>> On Jan 19, 2017, at 4:17 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> For those times when you _don't_ know how many elements there are, don't 
>> care, and for some reason can't be bothered to get `array.count`, but you 
>> need to explicitly access an element by its index *and* have a useful 
>> fallback value, IMO it's reasonable to have an alternative subscript like 
>> the proposed `array[lenient: 10]`. But with facilities like `for...in`, 
>> `map`, etc., and others like `count` and `enumerated`, it's hard to argue 
>> that it's nearly as common a scenario as those where you are given a 
>> known-good index.
>> 
> 
> I’m not sure why people keep asking for this; the extension is trivial so 
> anyone who wants it can have it:
> 
> extension Collection
> {
> subscript(ifExists index: Index) -> Iterator.Element? {
> guard index < self.endIndex else { return nil }
> return self[index]
> }
> }
> 
> // won't assert!
> myArray[ifExists: 42]
> 
> 
> 
> Russ
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Amen!

Although technically, you should do (startIndex..

Re: [swift-evolution] Strings in Swift 4

[Ben Cohen via swift-evolution]

> On Jan 20, 2017, at 3:29 PM, Jaden Geller via swift-evolution 
>  wrote:
> 
> Wouldn’t `x[…]` be more consistent with these other syntaxes?
> 

Maybe (though are those extra characters really telling you much?). 

But you can’t write that in Swift – you’d need a 0-argument operator.

(Or a […] postfix operator I guess if you wanted to try and sneak that through, 
but that is also not allowed…  :)


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

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Fri Jan 20 2017, Jonathan Hull  wrote:

> Perhaps we could separate the proposal from the manifesto, and then
> use the manifesto to collect future plans as well in all of the areas
> around string processing (which could later be broken off into smaller
> proposals), similar to how the Generics manifesto has been working?

Yes, that's the idea.  I guess my point is that while we want to flesh
these areas out, and they should go in the manifesto, I think now is the
wrong time to dive into the details.  We should leave the necessary
notes and placeholders in the manifesto so that we'll be able to come
back later and fill them in.


> My main concern with the Swift 4 process is that there are so many
> good ideas being thrown about, which are then deferred, but not really
> captured in a central/organized place… so we keep having the same
> discussion over and over.  Ultimately, I am convinced we need a
> separate facility/process for brainstorming about future proposals,
> but in the mean-time having a few manifestos capturing future ideas
> that we then use as guide posts that we are headed towards is a good
> step.
>
> Thanks,
> Jon
>
>> On Jan 20, 2017, at 2:20 PM, Dave Abrahams via swift-evolution
>  wrote:
>> 
>> 
>> on Fri Jan 20 2017, Gwendal Roué
>> > >
>> wrote:
>> 
 One ask - make string interpolation great again?
>>> 
>>> I have a dream, that ExpressibleByStringInterpolation would allow to 
>>> distinguish literal segments
>>> and embedded inputs.
>>> 
>>> Today, the documentation of this protocol [1] says:
>>> 
>>> "One cookie: $\(price), \(number) cookies: $\(price * number)."
>>> // <=>
>>> let message = String(stringInterpolation:
>>> String(stringInterpolationSegment: "One cookie: $"),
>>> String(stringInterpolationSegment: price),
>>> String(stringInterpolationSegment: ", "),
>>> String(stringInterpolationSegment: number),
>>> String(stringInterpolationSegment: " cookies: $"),
>>> String(stringInterpolationSegment: price * number),
>>> String(stringInterpolationSegment: "."))
>>> 
>>> This means that ExpressibleByStringInterpolation can't distinguish "foo" 
>>> from `bar` in "foo\(bar)".
>>> 
>>> If this distinction were possible, some nice features could emerge, such as 
>>> context-sensitive
>>> escaping:
>>> 
>>> // func render(_ html: HTML)
>>> let title = "boom();"
>>> render("\(title)") // escapes input
>>> 
>>> // func query(_ sql: SQL)
>>> let name = "Robert'); DROP TABLE students; --"
>>> query("SELECT * FROM students WHERE name = \(name)") // avoids SQL 
>>> injection
>>> 
>>> Ideally, a solution for multi-line literals (for strings and interpolated 
>>> strings) would be found,
>>> too.
>>> 
>>> I wish the manifesto would address these topics as well :-)
>> 
>> This is totally something we want to fix, but as part of a wholesale
>> reform of the ExpressibleByXXX protocols.  It's outside the scope of the
>> manifesto.
>> 
>> -- 
>> -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

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

Re: [swift-evolution] Strings in Swift 4

[Jordan Rose via swift-evolution]

>> 
>>  Are the backing representations for String also the same types that can be 
>> exposed statically (as in the mentioned `NFCNormalizedUTF16String`)?
> 
> Roughly.  I think we want at least the following backing representations for 
> String:
> 
> 1. The two compressed representations used by Cocoa "tagged pointer" strings
> 2. A third "tagged pointer" representation that stores 63 bits of UTF-16 (so 
> arbitrary UnicodeScalars and most Characters can be stored efficiently)
> 3. A known Latin-1 backing store that we can fast-path
> 4. A known UTF-16 backing store
> 5. A type-erased arbitrary (or nearly-arbitrary, if we have to accept a UTF16 
> subset restriction) instance of Unicode
> 
> It's possible that some of the representations in the range 3...5 can be 
> collapsed into one.

Cocoa's "tagged pointer" string actually has three representations, which 
external developer Mike Ash covered in detail on his blog 
:

> Thus we can see that the structure of the tagged pointer strings is:
> 
>   • If the length is between 0 and 7, store the string as raw eight-bit 
> characters.
>   • If the length is 8 or 9, store the string in a six-bit encoding, 
> using the alphabet "eilotrm.apdnsIc 
> ufkMShjTRxgC4013bDNvwyUL2O856P-B79AFKEWV_zGJ/HYX".
>   • If the length is 10 or 11, store the string in a five-bit encoding, 
> using the alphabet "eilotrm.apdnsIc ufkMShjTRxgC4013"

None of this is currently part of Foundation's ABI, of course, and technically 
it wouldn't have to be part of Swift's either. The particular thing I wanted to 
note is that they went with UTF-8 instead of UTF-16 for the non-alphabetic 
representation*; burning an additional representation that can store 3 UTF-16 
code units may or may not be worth it.

Jordan

* at least in 2015 when Mike Ash disassembled that particular Foundation. I'm 
not sure if we're allowed to share what Foundation is currently doing and if it 
is different.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Refactor Metatypes

[Douglas Gregor via swift-evolution]

> On Jan 20, 2017, at 12:37 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> Could someone tell if the proposal fits Phase 1? Seeing SE-0148—which doesn't 
> contain any ABI-breaking changes—being reviewed for Phase 1, I'm not sure 
> about anything.
> The PR should either be labeled "out of scope of current release", or merged. 
> Or maybe it contains some fundamental flaws that even prevent it from review?

SE-0148 fits in phase 1 because it’s in support of Phase 1 goals—specifically, 
it enables intended ABI-breaking changes in the standard library and is 
intended to be used as part of the String design.

AFAICT, the Refactoring Metatypes proposal is mostly independent. I view it as 
something that is important to look at in phase 2 because it is 
source-breaking, and if we’re going to do it, it should happen in Swift 4 
rather than Swift 5.

- Doug

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

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

[Jean-Daniel via swift-evolution]

> Le 20 janv. 2017 à 22:55, Howard Lovatt via swift-evolution 
>  a écrit :
> 
> In Java there is a hierarchy of errors, the idea is that you catch at 
> different severities. It isn't particularly well implemented in Java with a 
> weird hierarchy and errors strangely classified and poor naming. Despite 
> these glaring shortcoming it does actually work!
> 
> In Swift this general concept of user defined error type which have a 
> severity level  could be implemented, it might be:
> 
>protocol ProgramFatalError {} // Not possible to catch - terminates program
>protocol ThreadFatalError {} // Not possible to catch - terminates thread, 
> but calls thread's deinit - deinit has access to the error
>protocol Error {} // As is

How does TheadFatalError is supposed to behave in a world dominated by queue ?

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

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Fri Jan 20 2017, Joe Groff  wrote:

>> On Jan 20, 2017, at 8:28 AM, Dave Abrahams via swift-evolution
>  wrote:
>> 
>> 
>> 
>> 
>
>> 
>> 
>> 
>> 
>>> On Jan 20, 2017, at 5:48 AM, Jonathan Hull >> > wrote:
>>> 
>>> Thanks for all the hard work!
>>> 
>>> Still digesting, but I definitely support the goal of string processing 
>>> even better than Perl.  Some random thoughts:
>>> 
>>> • I also like the suggestion of implicit conversion from substring
>>> slices to strings based on a subtype relationship, since I keep
>>> running into that issue when trying to use array slices.
>> 
>> Interesting.  Could you offer some examples?
>> 
>>> It would be nice to be able to specify that conversion behavior with other 
>>> types that have a similar subtype relationship.
>> 
>> Indeed.
>> 
>>> • One thing that stood out was the interpolation format syntax, which 
>>> seemed a bit convoluted and difficult to parse:
 "Something with leading zeroes: \(x.format(fill: zero, width:8))"
>>> 
>>> 
>>> Have you considered treating the interpolation parenthesis more
>>> like the function call syntax?  It should be a familiar pattern and
>>> easily parseable to someone versed in other areas of swift:
>>> 
>>>   “Something with leading zeroes: \(x, fill: .zero, width: 8)"
>> 
>> Yes, we've considered it
>> 
>>  1. "\(f(expr1, label2: expr2, label3: expr3))" 
>> 
>> String(describing: f(expr1, label2: expr2, label3: expr3))
>> 
>>  2. "\(expr0 + expr1(label2: expr2, label3: expr3))"
>> 
>> String(describing: expr0 + expr1(label2: expr2, label3: expr3)
>> 
>>  3. "\((expr1, label2: expr2, label3: expr3))"
>> 
>> String(describing: (expr1, label2: expr2, label3: expr3))
>> 
>>  4. "\(expr1, label2: expr2, label3: expr3)"
>> 
>> String(describing: expr1, label2: expr2, label3: expr3)
>> 
>> I think I'm primarily concerned with the differences among cases 1, 3,
>> and 4, which are extremely minor.  3 and 4 differ by just a set of
>> parentheses, though that might be mitigated by the ${...} suggestion someone 
>> else posted.  The
>> point of using string interpolation is to improve
>> readability, and I fear these cases make too many things look alike that
>> have very different meanings.  Using a common term like "format" calls
>> out what is being done.
>
> We should look at this part of the problem as part of reconsidering
> the way string interpolation works as a whole; there are other
> problems with our current model, such as not being able to distinguish
> literal and non-literal segments. 

Yes.

> I fear that even this:
>
>> It's possible to produce terser versions of the syntax that don't suffer
>> from this problem by using a dedicated operator:
>> 
>>  "Column 1: \(n⛄(radix:16, width:8)) *** \(message)"
>>  "Something with leading zeroes: \(x⛄(fill: zero, width:8))"
>
> has too many nested delimiters to be easily readable. 

I agree.

> If we had a string interpolation protocol something like this:
>
> protocol ExpressibleByStringInterpolation {
>   associatedtype LiteralSegment: ExpressibleByStringLiteral
>   associatedtype InterpolatedSegment
>   init()
>
>   mutating func append(literalSegment: LiteralSegment)
>   mutating func append(interpolatedSegment: InterpolatedSegment)
> }
>
> and "now you have \(n, radix: 16, width: 2) problems" in 'Thingy' context 
> desugared so that \()
> became a constructor call on the InterpolatedSegment type:
>
> {
>   var x = Thingy()
>   x.append(literalSegment: "now you have ")
>   x.append(interpolatedSegment: Thingy.InterpolatedSegment(n, radix: 16, 
> width: 2))
>   x.append(literalSegment: " problems")
>   return x
> }()
>
> then String.InterpolatedSegment could be a struct that offers interesting 
> formatting initializers.

Maybe so.  But let's try not to get too caught up in the specifics of
formatting, as that's really not something we want to deal with right
now.

-- 
-Dave

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

Re: [swift-evolution] Strings in Swift 4

[Jaden Geller via swift-evolution]

> On Jan 20, 2017, at 2:57 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> The “Empty Subscript”
>> 
>> Empty subscript seems weird. IMO, it’s because of the asymmetry
>> between subscripts and computed properties. I would favour a model
>> which unifies computed properties and subscripts (e.g. computed
>> properties could return “addressors” for in-place mutation).
>> Maybe this could be an “entireCollection”/“entireSlice" computed
>> property?
> 
> It could, but x.entireSlice is syntactically heavyweight compared to
> x[], and x[] lives on a continuum with x[a...], x[..

Re: [swift-evolution] Strings in Swift 4

[Jonathan Hull via swift-evolution]

Perhaps we could separate the proposal from the manifesto, and then use the 
manifesto to collect future plans as well in all of the areas around string 
processing (which could later be broken off into smaller proposals), similar to 
how the Generics manifesto has been working?

My main concern with the Swift 4 process is that there are so many good ideas 
being thrown about, which are then deferred, but not really captured in a 
central/organized place… so we keep having the same discussion over and over.  
Ultimately, I am convinced we need a separate facility/process for 
brainstorming about future proposals, but in the mean-time having a few 
manifestos capturing future ideas that we then use as guide posts that we are 
headed towards is a good step.

Thanks,
Jon

> On Jan 20, 2017, at 2:20 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Fri Jan 20 2017, Gwendal Roué  > wrote:
> 
>>> One ask - make string interpolation great again?
>> 
>> I have a dream, that ExpressibleByStringInterpolation would allow to 
>> distinguish literal segments
>> and embedded inputs.
>> 
>> Today, the documentation of this protocol [1] says:
>> 
>>  "One cookie: $\(price), \(number) cookies: $\(price * number)."
>>  // <=>
>>  let message = String(stringInterpolation:
>>  String(stringInterpolationSegment: "One cookie: $"),
>>  String(stringInterpolationSegment: price),
>>  String(stringInterpolationSegment: ", "),
>>  String(stringInterpolationSegment: number),
>>  String(stringInterpolationSegment: " cookies: $"),
>>  String(stringInterpolationSegment: price * number),
>>  String(stringInterpolationSegment: "."))
>> 
>> This means that ExpressibleByStringInterpolation can't distinguish "foo" 
>> from `bar` in "foo\(bar)".
>> 
>> If this distinction were possible, some nice features could emerge, such as 
>> context-sensitive
>> escaping:
>> 
>>  // func render(_ html: HTML)
>>  let title = "boom();"
>>  render("\(title)") // escapes input
>> 
>>  // func query(_ sql: SQL)
>>  let name = "Robert'); DROP TABLE students; --"
>>  query("SELECT * FROM students WHERE name = \(name)") // avoids SQL 
>> injection
>> 
>> Ideally, a solution for multi-line literals (for strings and interpolated 
>> strings) would be found,
>> too.
>> 
>> I wish the manifesto would address these topics as well :-)
> 
> This is totally something we want to fix, but as part of a wholesale
> reform of the ExpressibleByXXX protocols.  It's outside the scope of the
> manifesto.
> 
> -- 
> -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

Re: [swift-evolution] Strings in Swift 4

[Sean Heber via swift-evolution]

>> * The talk about implicit conversions between Substring and String bums me
>> out, even though I see the importance of it in this context and know that
>> it outweighs the alternatives. Given that the Swift team seems to prefer
>> explicit to implicit conversions in general, I would hope that if they feel
>> it's important enough to make a special case for the standard library, it
>> could be a language feature that you'd consider making available to
>> anyone.
> 
> Not speaking for the whole team, I personally feel we should make it
> generally available, but I also recognize that we'll likely have to roll
> out the String reimplementation before we have time to properly design
> a general “struct subtyping” feature for end-users.

I may not be following this properly, but isn’t this sort of situation what 
protocols are for? Why couldn’t String be a protocol and there be something 
like UnicodeString and UnicodeSubstring and they both implement the String 
protocol?

l8r
Sean
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Fri Jan 20 2017, Karl Wagner  wrote:

> Very nice improvements overall!
>
>> To ease the pain of type mismatches, Substring should be a subtype
>> of String in the same way that Int is a subtype of
>> Optional. This would give users an implicit conversion from
>> Substring to String, as well as the usual implicit conversions such
>> as [Substring] to [String] that other subtype relationships receive.
>
> As others have said, it would be nice for this to be more
> general. Perhaps we can have a special type or protocol, something
> like RecursiveSlice?

A general feature for subtyping is out-of-scope for the String
redesign, so I ask that you bring it up in a separate discussion.

>> A Substring passed where String is expected will be implicitly
>> copied. When compared to the “same type, copied storage” model, we
>> have effectively deferred the cost of copying from the point where a
>> substring is created until it must be converted to Stringfor use
>> with an API.
>
> Could noescape parameters/new memory model with borrowing make this
> more general? 

It makes everything more general.  That said, we don't have a design
yet, and one of the important premises is that users who don't want to
think about borrowing won't have to.  So because we have to design
Strings for the language we have today, and because they have to work
in a user-model without borrowing, we're going to focus on traditional
copyable value semantics.

> Again it seems very useful for all kinds of Collections.  


> The “Empty Subscript”
> 
> Empty subscript seems weird. IMO, it’s because of the asymmetry
> between subscripts and computed properties. I would favour a model
> which unifies computed properties and subscripts (e.g. computed
> properties could return “addressors” for in-place mutation).
> Maybe this could be an “entireCollection”/“entireSlice" computed
> property?

It could, but x.entireSlice is syntactically heavyweight compared to
x[], and x[] lives on a continuum with x[a...], x[..> The goal is that Unicode exposes the underlying encoding and code
>> units in such a way that for types with a known representation
>> (e.g. a high-performance UTF8String) that information can be known
>> at compile-time and can be used to generate a single path, while
>> still allowing types like String that admit multiple representations
>> to use runtime queries and branches to fast path specializations.
>
> Typo: “unicodeScalars" is in the protocol twice.

Nice catch!

> If I understand it, CodeUnits is the thing which should always be
> defined by conformers to Unicode, and UnicodeScalars and ExtendedASCII
> could have default implementations (for example,
> UTF8String/UTF16String/3rd party conformers will use those), and
> String might decide to return its native buffer (e.g. if
> Encoding.CodeUnit == UnicodeScalar).

Yes.  I'm not certain that associated types are needed for anything but
the CodeUnits, FWIW.

> I’m just wondering how difficult it would be for a 3rd-party type to
> conform to Unicode. If you’re developing a text editor, for example,
> it’s possible that you may need to implement your own String-like type
> with some optimised storage model and it would be nice to be able to
> use generic algorithms with them. I’m thinking that you will have some
> kind of backing buffer, and you will want to expose regions of that to
> clients as Strings so that they can render them for UI or search
> through them, etc, without introducing a copy just for the semantic
> understanding that this data region contains some text content.
>
> I’ll need to examine the generic String idea more, but it’s certainly
> very interesting...
>
>> Indexes
>
> One thing which I think it critical is the ability to advance an index
> by a given number of codeUnits. I was writing some code which
> interfaced with the Cocoa NSTextStorage class, tagging parts of a
> string that a user was editing. If this was an Array, when the user
> inserts some elements before your stored indexes, those indexes become
> invalid but you can easily advance by the difference to efficiently
> have your indexes pointing to the same characters.

  a = Index(codeUnitOffset: a.codeUnitOffset + 5)

> Currently, that’s impossible with String. 

No, it's just super-cumbersome.  You have to go through the utf16 view.
But I agree we need to make it easier.

> If the user inserts a string at a given index, your old indexes may
> not even point to the start of a grapheme cluster any more, and
> advancing the index is needlessly costly. For example:
>
> var characters = "This is a test".characters
> assert(characters.count == 14)
>
> // Store an index to something.
> let endBeforePrepending = characters.endIndex
>
> // Insert some characters somewhere.
> let insertedCharacters = "[PREPENDED]".characters
> assert(insertedCharacters.count == 11)
> characters.replaceSubrange(characters.startIndex.. with: 

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Fri Jan 20 2017, Tony Allevato  wrote:

> I'm excited to see this taking shape. Thanks for all the hard work putting
> this together!
>
> A few random thoughts I had while reading it:
>
> * You talk about an integer `codeUnitOffset` property for indexes. Since
> the current String implementation can switch between backing storage of
> ASCII or UTF-16 depending on the content of the string and how it's
> obtained, presumably this means that integer is not necessarily the same as
> the offset into the buffer, correct? (In other words, for a UTF-16-stored
> string, you would have to multiply it by 2.)

Details of the buffer should not be exposed to users in the API.  This
is not an offset in bytes, but an offset in codeUnits.  Expressing
that was the point of the name `codeUnitOffset`.  Maybe we could have
chosen better.

> * You discuss the possibility of exposing some String methods, like
> `uppercase()`, on Character. Since Swift abstracts away the encoding, it
> seems like Characters are essentially Strings that are enforced at runtime
> (and sometimes at compile time, in the case of initialization from
> literals) to contain exactly 1 grapheme cluster. Given that, I think it
> would be worthwhile for Character to support *any* method on String that
> would be sensical to operate on a single character—case transformations
> (though perhaps not titlecase?), accessing its UTF-8 or UTF-16 views, and
> so forth. 

We thought about that; it would essentially mean conforming `Character`
to `Unicode`, which would make `Character` a `BidirectionalCollection`
of `Character` elements.  I was worried that it might be confusing for
users, so didn't want to propose it.  It's hard to say whether it would
in fact be OK.

> I would ask whether it makes sense to have a shared protocol between
> Character and String that defines those methods, but I'll defer on
> that because it feels like it would be a "bag of methods" rather than
> semantically meaningful.
>
> On that same point, if I have a lightweight (<= 63 bit) Character, many of
> those operations can only currently be performed by constructing a String
> from it, which incurs a time and heap allocation penalty. (And indeed,
> there are TODOs in the code base to avoid doing such things internally, in
> the case of Character comparisons.) Which leads me to my next thought,
> since I've been doing a lot with Swift String performance lately...
>
> * Currently, Character and String have divergent internal implementations.
> A Character can be "small" (<= 63 bits in UTF-8 packed into an integer) or
> "large" (> 63 bits with a heap-allocated buffer). 

We've been meaning to make Character's "small" representation be UTF-16,
and we intend to give String a few "small" representations.

> Strings are just backed by a heap-allocated buffer. In this write-up,
> you say "Many strings are short enough to store in 64 bits"—not just
> characters. If that's the case, can those optimizations be lowered
> into _StringCore (or its new-world counterpart), which would allow
> both Characters *and* small Strings to reap the benefits of the more
> efficient implementation? 

That's the plan.

> This would let Characters get implementations of common methods like
> `uppercase()` for free, and there would be a zero-cost conversion from
> Characters to Strings.  The only real difference between the types
> would be the APIs they vend, the semantic concept that they represent
> to users, and validation.
>
> * The talk about implicit conversions between Substring and String bums me
> out, even though I see the importance of it in this context and know that
> it outweighs the alternatives. Given that the Swift team seems to prefer
> explicit to implicit conversions in general, I would hope that if they feel
> it's important enough to make a special case for the standard library, it
> could be a language feature that you'd consider making available to
> anyone.

Not speaking for the whole team, I personally feel we should make it
generally available, but I also recognize that we'll likely have to roll
out the String reimplementation before we have time to properly design
a general “struct subtyping” feature for end-users.

> On Fri, Jan 20, 2017 at 7:35 AM Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jan 19, 2017, at 10:42 PM, Jose Cheyo Jimenez 
>> wrote:
>>
>> I just have one concern about the slice of a string being called
>> Substring. Why not StringSlice? The word substring can mean so many things,
>> specially in cocoa.
>>
>>
>> This idea has a lot of merit, as does the option of not giving them a
>> top-level name at all e.g. they could be String.Slice or
>> String.SubSequence. It would underscore that they really aren’t meant to be
>> used except as the result of a slicing operation or to efficiently pass a
>> slice. OTOH, Substring is a term of art so can help with clarity.
>>
>>
>> 

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Fri Jan 20 2017, Joe Groff  wrote:

> Jordan points out that the generalized slicing syntax stomps on '...x'
> and 'x...', which would be somewhat obvious candidates for variadic
> splatting if that ever becomes a thing. Now, variadics are a much more
> esoteric feature and slicing is much more important to day-to-day
> programming, so this isn't the end of the world IMO, but it is
> something we'd be giving up.

Good point, Jordan.

-- 
-Dave

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

Re: [swift-evolution] Strings in Swift 4

[Matthew Johnson via swift-evolution]

This looks really great to me.  I am not an expert in this area so I don’t have 
a lot of detailed comments.  That said, it looks like it will significantly 
improve the string handling experience of app developers, including better 
bridging to the APIs we work with every day.

I did notice one particularly interesting thing in the sketch of the Unicode 
protocol.  This section specifically calls out that it relies on features that 
are “planned but not yet implemented”.  I was surprised to see this:

extension Unicode : RangeReplaceableCollection where CodeUnits :
  RangeReplaceableCollection

Conformances via protocol extensions is listed as “unlikely” in the generics 
manifesto.  Has something changed such that this is now a “planned” feature (or 
at least less “unlikely”)?


> On Jan 19, 2017, at 8:56 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Below is our take on a design manifesto for Strings in Swift 4 and beyond.
> 
> Probably best read in rendered markdown on GitHub:
> https://github.com/apple/swift/blob/master/docs/StringManifesto.md
> 
> We’re eager to hear everyone’s thoughts.
> 
> Regards,
> Ben and Dave
> 
> 
> # String Processing For Swift 4
> 
> * Authors: [Dave Abrahams](https://github.com/dabrahams), [Ben 
> Cohen](https://github.com/airspeedswift)
> 
> The goal of re-evaluating Strings for Swift 4 has been fairly ill-defined thus
> far, with just this short blurb in the
> [list of 
> goals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html):
> 
>> **String re-evaluation**: String is one of the most important fundamental
>> types in the language.  The standard library leads have numerous ideas of how
>> to improve the programming model for it, without jeopardizing the goals of
>> providing a unicode-correct-by-default model.  Our goal is to be better at
>> string processing than Perl!
> 
> For Swift 4 and beyond we want to improve three dimensions of text processing:
> 
>  1. Ergonomics
>  2. Correctness
>  3. Performance
> 
> This document is meant to both provide a sense of the long-term vision 
> (including undecided issues and possible approaches), and to define the scope 
> of
> work that could be done in the Swift 4 timeframe.
> 
> ## General Principles
> 
> ### Ergonomics
> 
> It's worth noting that ergonomics and correctness are mutually-reinforcing.  
> An
> API that is easy to use—but incorrectly—cannot be considered an ergonomic
> success.  Conversely, an API that's simply hard to use is also hard to use
> correctly.  Acheiving optimal performance without compromising ergonomics or
> correctness is a greater challenge.
> 
> Consistency with the Swift language and idioms is also important for
> ergonomics. There are several places both in the standard library and in the
> foundation additions to `String` where patterns and practices found elsewhere
> could be applied to improve usability and familiarity.
> 
> ### API Surface Area
> 
> Primary data types such as `String` should have APIs that are easily 
> understood
> given a signature and a one-line summary.  Today, `String` fails that test.  
> As
> you can see, the Standard Library and Foundation both contribute 
> significantly to
> its overall complexity.
> 
> **Method Arity** | **Standard Library** | **Foundation**
> ---|:---:|:---:
> 0: `ƒ()` | 5 | 7
> 1: `ƒ(:)` | 19 | 48
> 2: `ƒ(::)` | 13 | 19
> 3: `ƒ(:::)` | 5 | 11
> 4: `ƒ()` | 1 | 7
> 5: `ƒ(:)` | - | 2
> 6: `ƒ(::)` | - | 1
> 
> **API Kind** | **Standard Library** | **Foundation**
> ---|:---:|:---:
> `init` | 41 | 18
> `func` | 42 | 55
> `subscript` | 9 | 0
> `var` | 26 | 14
> 
> **Total: 205 APIs**
> 
> By contrast, `Int` has 80 APIs, none with more than two parameters.[0] String 
> processing is complex enough; users shouldn't have
> to press through physical API sprawl just to get started.
> 
> Many of the choices detailed below contribute to solving this problem,
> including:
> 
>  * Restoring `Collection` conformance and dropping the `.characters` view.
>  * Providing a more general, composable slicing syntax.
>  * Altering `Comparable` so that parameterized
>(e.g. case-insensitive) comparison fits smoothly into the basic syntax.
>  * Clearly separating language-dependent operations on text produced 
>by and for humans from language-independent
>operations on text produced by and for machine processing.
>  * Relocating APIs that fall outside the domain of basic string processing and
>discouraging the proliferation of ad-hoc extensions.
> 
> 
> ### Batteries Included
> 
> While `String` is available to all programs out-of-the-box, crucial APIs for
> basic string processing tasks are still inaccessible until `Foundation` is
> imported.  While it makes sense that `Foundation` is needed for 
> domain-specific
> jobs such as
> [linguistic 
> tagging](https://developer.apple.com/reference/foundation/nslinguistictagger),
> one should not need to import anything 

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Fri Jan 20 2017, Gwendal Roué  wrote:

>> One ask - make string interpolation great again?
>
> I have a dream, that ExpressibleByStringInterpolation would allow to 
> distinguish literal segments
> and embedded inputs.
>
> Today, the documentation of this protocol [1] says:
>
>   "One cookie: $\(price), \(number) cookies: $\(price * number)."
>   // <=>
>   let message = String(stringInterpolation:
>   String(stringInterpolationSegment: "One cookie: $"),
>   String(stringInterpolationSegment: price),
>   String(stringInterpolationSegment: ", "),
>   String(stringInterpolationSegment: number),
>   String(stringInterpolationSegment: " cookies: $"),
>   String(stringInterpolationSegment: price * number),
>   String(stringInterpolationSegment: "."))
>
> This means that ExpressibleByStringInterpolation can't distinguish "foo" from 
> `bar` in "foo\(bar)".
>
> If this distinction were possible, some nice features could emerge, such as 
> context-sensitive
> escaping:
>
>   // func render(_ html: HTML)
>   let title = "boom();"
>   render("\(title)") // escapes input
>
>   // func query(_ sql: SQL)
>   let name = "Robert'); DROP TABLE students; --"
>   query("SELECT * FROM students WHERE name = \(name)") // avoids SQL 
> injection
>
> Ideally, a solution for multi-line literals (for strings and interpolated 
> strings) would be found,
> too.
>
> I wish the manifesto would address these topics as well :-)

This is totally something we want to fix, but as part of a wholesale
reform of the ExpressibleByXXX protocols.  It's outside the scope of the
manifesto.

-- 
-Dave

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

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

[Howard Lovatt via swift-evolution]

In Java there is a hierarchy of errors, the idea is that you catch at different 
severities. It isn't particularly well implemented in Java with a weird 
hierarchy and errors strangely classified and poor naming. Despite these 
glaring shortcoming it does actually work!

In Swift this general concept of user defined error type which have a severity 
level  could be implemented, it might be:

protocol ProgramFatalError {} // Not possible to catch - terminates program
protocol ThreadFatalError {} // Not possible to catch - terminates thread, 
but calls thread's deinit - deinit has access to the error
protocol Error {} // As is

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

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

on Thu Jan 19 2017, Saagar Jha  wrote:

> Looks pretty good in general from my quick glance–at least, it’s much
> better than the current situation. I do have a couple of comments and
> questions, which I’ve inlined below.
>
> Saagar Jha
>
>> On Jan 19, 2017, at 6:56 PM, Ben Cohen via swift-evolution
>  wrote:
>> 
>> Hi all,
>> 
>> Below is our take on a design manifesto for Strings in Swift 4 and beyond.
>> 
>> Probably best read in rendered markdown on GitHub:
>> https://github.com/apple/swift/blob/master/docs/StringManifesto.md
>> 
>> We’re eager to hear everyone’s thoughts.
>> 
>> Regards,
>> Ben and Dave
>> 
>> 
>> # String Processing For Swift 4
>> 
>> * Authors: [Dave Abrahams](https://github.com/dabrahams), [Ben
> Cohen](https://github.com/airspeedswift)
>> 
>> The goal of re-evaluating Strings for Swift 4 has been fairly ill-defined 
>> thus
>> far, with just this short blurb in the
>> [list of
> goals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html):
>> 
>>> **String re-evaluation**: String is one of the most important fundamental
>>> types in the language.  The standard library leads have numerous ideas of 
>>> how
>>> to improve the programming model for it, without jeopardizing the goals of
>>> providing a unicode-correct-by-default model.  Our goal is to be better at
>>> string processing than Perl!
>> 
>> For Swift 4 and beyond we want to improve three dimensions of text 
>> processing:
>> 
>>  1. Ergonomics
>>  2. Correctness
>>  3. Performance
>> 
>> This document is meant to both provide a sense of the long-term vision 
>> (including undecided issues and possible approaches), and to define the 
>> scope of
>> work that could be done in the Swift 4 timeframe.
>> 
>> ## General Principles
>> 
>> ### Ergonomics
>> 
>> It's worth noting that ergonomics and correctness are mutually-reinforcing.  
>> An
>> API that is easy to use—but incorrectly—cannot be considered an ergonomic
>> success.  Conversely, an API that's simply hard to use is also hard to use
>> correctly.  Acheiving optimal performance without compromising ergonomics or
>> correctness is a greater challenge.
>
> Minor typo: acheiving->achieving
>
>> Consistency with the Swift language and idioms is also important for
>> ergonomics. There are several places both in the standard library and in the
>> foundation additions to `String` where patterns and practices found elsewhere
>> could be applied to improve usability and familiarity.
>> 
>> ### API Surface Area
>> 
>> Primary data types such as `String` should have APIs that are easily 
>> understood
>> given a signature and a one-line summary.  Today, `String` fails that test.  
>> As
>> you can see, the Standard Library and Foundation both contribute 
>> significantly to
>> its overall complexity.
>> 
>> **Method Arity** | **Standard Library** | **Foundation**
>> ---|:---:|:---:
>> 0: `ƒ()` | 5 | 7
>> 1: `ƒ(:)` | 19 | 48
>> 2: `ƒ(::)` | 13 | 19
>> 3: `ƒ(:::)` | 5 | 11
>> 4: `ƒ()` | 1 | 7
>> 5: `ƒ(:)` | - | 2
>> 6: `ƒ(::)` | - | 1
>> 
>> **API Kind** | **Standard Library** | **Foundation**
>> ---|:---:|:---:
>> `init` | 41 | 18
>> `func` | 42 | 55
>> `subscript` | 9 | 0
>> `var` | 26 | 14
>> 
>> **Total: 205 APIs**
>> 
>> By contrast, `Int` has 80 APIs, none with more than two
> parameters.[0] String processing is complex enough; users shouldn't
> have
>> to press through physical API sprawl just to get started.
>> 
>> Many of the choices detailed below contribute to solving this problem,
>> including:
>> 
>>  * Restoring `Collection` conformance and dropping the `.characters` view.
>>  * Providing a more general, composable slicing syntax.
>>  * Altering `Comparable` so that parameterized
>>(e.g. case-insensitive) comparison fits smoothly into the basic syntax.
>>  * Clearly separating language-dependent operations on text produced 
>>by and for humans from language-independent
>>operations on text produced by and for machine processing.
>>  * Relocating APIs that fall outside the domain of basic string processing 
>> and
>>discouraging the proliferation of ad-hoc extensions.
>> 
>> 
>> ### Batteries Included
>> 
>> While `String` is available to all programs out-of-the-box, crucial APIs for
>> basic string processing tasks are still inaccessible until `Foundation` is
>> imported.  While it makes sense that `Foundation` is needed for 
>> domain-specific
>> jobs such as
>> [linguistic 
>> tagging](https://developer.apple.com/reference/foundation/nslinguistictagger),
>> one should not need to import anything to, for example, do case-insensitive
>> comparison.
>> 
>> ### Unicode Compliance and Platform Support
>> 
>> The Unicode standard provides a crucial objective reference point for what
>> constitutes correct behavior in an extremely complex domain, so
>> Unicode-correctness is, and will remain, a fundamental design principle 
>> behind
>> Swift's `String`.  

Re: [swift-evolution] Proposal: Remove the "fallthrough" keyword

[Joe Groff via swift-evolution]

> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Sat Dec 05 2015, jgr...@apple.com (Joe Groff) wrote:
> 
>>> On Dec 5, 2015, at 10:13 AM, David Owens II  wrote:
>>> 
>>> Is there a reason we cannot use labelled case statements?
>>> 
>>>switch some_value {
>>>case .REFINED:
>>>if !validate(some_value) { return NULL }
>>>fallthrough base
>>> 
>>>base: case .BASE:
>>>handle_enum_value();
>>>}
>>> 
>>> At least this is explicit now.
>> 
>> Yeah, maybe there's a more general language feature that could replace 
>> 'fallthrough' here. Instead
>> of labelling cases, we could support a 'reswitch' statement that 
>> redispatches the switch to the case
>> matching the operand:
>> 
>>switch some_value {
>>case .REFINED:
>>if !validate(some_value) { return NULL }
>>reswitch .BASE
>> 
>>case .BASE:
>>handle_enum_value();
>>}
> 
> We should just call a spade a spade and spell that "goto" ;-)

Cool by me. This does have the nice benefit over traditional 'goto' that each 
strand of spaghetti at least has a well-defined lexical scope, and a controlled 
way of passing state among scopes by pattern matching.

-Joe

> 
>> That should be easy to peephole to a proper fallthrough in constant cases, 
>> but would also nicely
>> generalize to applications like interpreters, where it's often desirable to 
>> push the dispatch inline
>> into the logic for better pipelining.
>> 
>> -Joe
>> 
>>> 
 On Dec 5, 2015, at 10:04 AM, Vinicius Vendramini >>> > gmail.com>> wrote:
 
 I understand there might be some cases in which the syntax provided
 is indeed useful for experienced programmers writing their
 code. However, in almost all the examples here, I had to struggle
 to understand the logic behind the code. Not because it’s poorly
 written... probably because this syntax may be used for many
 different purposes, so it’s hard to get what exactly is the intent
 behind each use.
 
 In Pierre’s latest example, for instance, it took me a few seconds
 to understand what was going on. I know it’s a simplified case, but
 it seems clearer to me to just write something like
 
 if some_value == .Refined && !validate(some_value) {
return NULL
 }
 handle_enum_value()
 
 More complex cases make for a better argument for `switch`es,
 mainly because they avoid big `if` pyramids, but especially in
 those I feel the resulting code is significantly harder to
 understand.
 
> On Dec 5, 2015, at 12:15 PM, Pierre Habouzit  > wrote:
> 
> 
>> On Dec 5, 2015, at 9:02 AM, Chris Lattner > > wrote:
>> 
>> On Dec 4, 2015, at 2:05 PM, jalkut at red-sweater.com > red-sweater.com> wrote:
>>> In the spirit of some other proposals that remove C or C++ style
>>> artifacts, what do folks think about the possibility of removing
>>> the "fallthrough" keyword from the language?
>> 
>> I’m not making an argument either way, but I want to point
>> something out: there is a major difference between fallthrough vs
>> ++/c-style-for.  To someone who doesn’t know them, the later are
>> "syntactic magic” with no reasonable way to decipher other than
>> looking them up somewhere.  The former is an English word whose
>> meaning is obvious in context.
>> 
>> All I’m saying is that to a reader of code, the “badness” of ++
>> and c-style for loops is greater than the “badness" of
>> fallthrough.
> 
> Given that Swift has the goal to also be a low level language, 
> fallthrough is really useful for conciseness and readability.
> 
> in system programming C, I find myself writing things like this very 
> often:
> 
> 
> switch (some_value) {
> case ENUM_VALUE_REFINED:
>if (validate(some_value)) {
>return NULL;
>}
>/* fallthrough */
> case ENUM_VALUE_BASE:
>handle_enum_value();
>…
> }
> 
> Where the swift equivalent would roughly be:
> 
> switch some_value {
> case .REFINED:
>if !validate(some_value) { return NULL }
>fallthrough
> case .BASE:
>handle_enum_value();
> }
> 
> This is as readable as it gets and is a pattern that the libdispatch has 
> in several places e.g.
> 
> Of course, you cannot fall through to arbitrary cases, so things like 
> this C code cannot be done in swift:
> 
> switch (some_value) {
> case ENUM_VALUE_REFINED_1:
>if (validate(some_value)) {
>return NULL;
>}
>goto base_value;
> case ENUM_VALUE_REFINED_2:
>if (validate(some_value)) {
>return NULL;
>}
>goto base_value;
> 

Re: [swift-evolution] Proposal: Remove the "fallthrough" keyword

[Dave Abrahams via swift-evolution]

on Sat Dec 05 2015, jgr...@apple.com (Joe Groff) wrote:

>> On Dec 5, 2015, at 10:13 AM, David Owens II  wrote:
>> 
>> Is there a reason we cannot use labelled case statements?
>> 
>> switch some_value {
>> case .REFINED:
>> if !validate(some_value) { return NULL }
>> fallthrough base
>> 
>> base: case .BASE:
>> handle_enum_value();
>> }
>> 
>> At least this is explicit now.
>
> Yeah, maybe there's a more general language feature that could replace 
> 'fallthrough' here. Instead
> of labelling cases, we could support a 'reswitch' statement that redispatches 
> the switch to the case
> matching the operand:
>
> switch some_value {
> case .REFINED:
> if !validate(some_value) { return NULL }
> reswitch .BASE
>
> case .BASE:
> handle_enum_value();
> }

We should just call a spade a spade and spell that "goto" ;-)

> That should be easy to peephole to a proper fallthrough in constant cases, 
> but would also nicely
> generalize to applications like interpreters, where it's often desirable to 
> push the dispatch inline
> into the logic for better pipelining.
>
> -Joe
>
>> 
>>> On Dec 5, 2015, at 10:04 AM, Vinicius Vendramini >>  gmail.com>> wrote:
>>> 
>>> I understand there might be some cases in which the syntax provided
>>> is indeed useful for experienced programmers writing their
>>> code. However, in almost all the examples here, I had to struggle
>>> to understand the logic behind the code. Not because it’s poorly
>>> written... probably because this syntax may be used for many
>>> different purposes, so it’s hard to get what exactly is the intent
>>> behind each use.
>>> 
>>> In Pierre’s latest example, for instance, it took me a few seconds
>>> to understand what was going on. I know it’s a simplified case, but
>>> it seems clearer to me to just write something like
>>> 
>>> if some_value == .Refined && !validate(some_value) {
>>> return NULL
>>> }
>>> handle_enum_value()
>>> 
>>> More complex cases make for a better argument for `switch`es,
>>> mainly because they avoid big `if` pyramids, but especially in
>>> those I feel the resulting code is significantly harder to
>>> understand.
>>> 
 On Dec 5, 2015, at 12:15 PM, Pierre Habouzit >>> > wrote:
 
 
> On Dec 5, 2015, at 9:02 AM, Chris Lattner  > wrote:
> 
> On Dec 4, 2015, at 2:05 PM, jalkut at red-sweater.com  red-sweater.com> wrote:
>> In the spirit of some other proposals that remove C or C++ style
>> artifacts, what do folks think about the possibility of removing
>> the "fallthrough" keyword from the language?
> 
> I’m not making an argument either way, but I want to point
> something out: there is a major difference between fallthrough vs
> ++/c-style-for.  To someone who doesn’t know them, the later are
> "syntactic magic” with no reasonable way to decipher other than
> looking them up somewhere.  The former is an English word whose
> meaning is obvious in context.
> 
> All I’m saying is that to a reader of code, the “badness” of ++
> and c-style for loops is greater than the “badness" of
> fallthrough.
 
 Given that Swift has the goal to also be a low level language, fallthrough 
 is really useful for conciseness and readability.
 
 in system programming C, I find myself writing things like this very often:
 
 
 switch (some_value) {
 case ENUM_VALUE_REFINED:
 if (validate(some_value)) {
 return NULL;
 }
 /* fallthrough */
 case ENUM_VALUE_BASE:
 handle_enum_value();
 …
 }
 
 Where the swift equivalent would roughly be:
 
 switch some_value {
 case .REFINED:
 if !validate(some_value) { return NULL }
 fallthrough
 case .BASE:
 handle_enum_value();
 }
 
 This is as readable as it gets and is a pattern that the libdispatch has 
 in several places e.g.
 
 Of course, you cannot fall through to arbitrary cases, so things like this 
 C code cannot be done in swift:
 
 switch (some_value) {
 case ENUM_VALUE_REFINED_1:
 if (validate(some_value)) {
 return NULL;
 }
 goto base_value;
 case ENUM_VALUE_REFINED_2:
 if (validate(some_value)) {
 return NULL;
 }
 goto base_value;
 
 case ENUM_VALUE_BASE:
 base_value:
 handle_enum_value();
 …
 }
 
 
 cannot be written in swift, despite also being quite useful.
 
 Jumping between arbitrary points inside a switch is disgusting. jumping 
 from label to label is useful and not harmful especially in swift where 
 you can’t place code between the “switch” and the first case.
 
 -Pierre
 
 

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

[Goffredo Marocchi via swift-evolution]

Ah... we will be missing hiding behind the warm embrace of message 
passing/dynamic dispatch :P

Sent from my iPhone

> On 20 Jan 2017, at 19:24, Pierre Monod-Broca via swift-evolution 
>  wrote:
> 
> The way I understand it, it's a bad idea to override == and != (or any infix 
> operator) for Sub if Super has them and that's why the default implementation 
> from Equatable only generates !=(Super, Super) and not !=(Sub, Sub) (and 
> there is no ==(Sub, Sub) generated either).
> 
> And it's a bad idea because (without dynamic dispatch on both operands) it 
> leads to unexpected behavior.
> 
> Considering :
> ```
> func ==(lhs: Super, rhs: Super) -> Bool {
> print("Super")
> return true
> }
> 
> func ==(lhs: Sub, rhs: Sub) -> Bool {
> print("Sub")
> return false
> }
> 
> let a = Sub()
> let b = Sub()
> a == b // Sub
> a as Super == b // Super
> a == b as Super // Super
> à as Super == b as Super // Super
> ```
> 
> One would compare the same objects and don't get the same result.
> 
> Instead you have to check the dynamic type yourself.
> 
> 
> Pierre
> 
>> Le 20 janv. 2017 à 10:45, Francisco Javier Fernández Toro via 
>> swift-evolution  a écrit :
>> 
>> 
>> 
>>> On Wed, Jan 18, 2017 at 6:58 PM, Tony Allevato  
>>> wrote:
>>> Ok, this actually does feel a bit strange. The behavior you're seeing seems 
>>> to be a consequence of 
>>> [SE-0091](https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md),
>>>  but it looks like you're seeing different behavior than what I described 
>>> in the "Class types and inheritance" section of that proposal.
>>> 
>>> If Sub has `==(Sub, Sub)` implemented as a *static* function, I just tried 
>>> it and it's *ignored* (`==(Super, Super)` gets called instead), even when 
>>> the two actual arguments are known to be statically of type Sub. I think 
>>> this is because of the way that proposal was implemented: when it sees that 
>>> `Sub` extends `Super`, which conforms to `Equatable`, it appears that it's 
>>> only looking for static overloads of `==` that are satisfied at the *point 
>>> of conformance*, which would be `==(Super, Super)` (because `Super` 
>>> conforms to `Equatable where Self == Super`). The wording of the proposal 
>>> makes this case: "Then, we say that we do not consider an operator function 
>>> if it implements a protocol requirement, because the requirement is a 
>>> generalization of all of the operator functions that satisfy that 
>>> requirement."
>>> 
>>> Contrarily, if you provide `==(Sub, Sub)` as a global function instead of a 
>>> static one, it *does* get called. I think in this case, the type checker 
>>> gets the whole set of candidate operators (which, unlike above, includes 
>>> the global `==(Sub, Sub)`), and it gets used because it's a more specific 
>>> match?
>>> 
>> 
>> FWIW, I've just changed both `==` functions to make them global, the the 
>> outcome is still the same, its using `==(Super,Super)` to resolve 
>> `!=(Sub,Sub)
>>  
>>> Can someone from the core team chime in and say whether this is intentional 
>>> behavior? It feels wrong that simply changing the location where the 
>>> operator is defined would change the behavior like this.
>>> 
>>> FWIW, to avoid these sharp edges, there's no need to implement `==` for 
>>> subtypes; since you have to use an overridable `equals` method anyway, just 
>>> have the base type implement `==` to delegate to it, and then have subtypes 
>>> override `equals` alone.
>>> 
>>> 
 On Wed, Jan 18, 2017 at 9:36 AM Francisco Javier Fernández Toro 
  wrote:
 Yeah guys, you are right, my code is busted, I was trying to point 
 something different out:
 
 The next code is showing the possible issue. In theory to make a class 
 Equatable, you just have to mark it with the Equatable protocol and 
 implement `==` as a static function or as a global one.
 
 If you don't override the equal method and you just invoke your super 
 class equality method you'll get something like this: 
 
 ```
 class Superclass : Equatable {
 let foo: Int
 
 init(foo: Int) { self.foo = foo }
 
 func equal(to: Superclass) -> Bool {
 return foo == to.foo
 }
 
 static func == (lhs: Superclass, rhs: Superclass) -> Bool {
 return lhs.equal(to: rhs)
 }
 }
 
 class Subclass: Superclass {
 let bar: Int
 init(foo: Int, bar: Int) {
 self.bar = bar
 super.init(foo: foo)
 }
 
 func equal(to: Subclass) -> Bool {
 return bar == to.bar && super.equal(to: to)
 }
 
 static func == (lhs: Subclass, rhs: Subclass) -> Bool {
 return lhs.equal(to: rhs)
 }
 }
 
 class 

Re: [swift-evolution] Strings in Swift 4

[Sean Heber via swift-evolution]

Syntax-wise, it almost seems like there shouldn’t be a comma after the variable 
name because then it looks like an argument to a function. What if it was just 
a space?

"now you have \(n radix: 16, width: 2) problems"

Anyway, this seems cool. :)

l8r
Sean






> On Jan 20, 2017, at 1:19 PM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On Jan 20, 2017, at 8:28 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>> 
>> 
>> Sent from my iPad
>>> On Jan 20, 2017, at 5:48 AM, Jonathan Hull  wrote:
>>> 
>>> Thanks for all the hard work!
>>> 
>>> Still digesting, but I definitely support the goal of string processing 
>>> even better than Perl.  Some random thoughts:
>>> 
>>> • I also like the suggestion of implicit conversion from substring slices 
>>> to strings based on a subtype relationship, since I keep running into that 
>>> issue when trying to use array slices.  
>> 
>> Interesting.  Could you offer some examples?
>> 
>>> It would be nice to be able to specify that conversion behavior with other 
>>> types that have a similar subtype relationship.
>> 
>> Indeed.
>> 
>>> • One thing that stood out was the interpolation format syntax, which 
>>> seemed a bit convoluted and difficult to parse:
 "Something with leading zeroes: \(x.format(fill: zero, width:8))"
>>> 
>>> 
>>> Have you considered treating the interpolation parenthesis more like the 
>>> function call syntax?  It should be a familiar pattern and easily parseable 
>>> to someone versed in other areas of swift:
>>> 
>>>   “Something with leading zeroes: \(x, fill: .zero, width: 8)"
>> 
>> Yes, we've considered it
>> 
>>  1. "\(f(expr1, label2: expr2, label3: expr3))" 
>> 
>> String(describing: f(expr1, label2: expr2, label3: expr3))
>> 
>>  2. "\(expr0 + expr1(label2: expr2, label3: expr3))"
>> 
>> String(describing: expr0 + expr1(label2: expr2, label3: expr3)
>> 
>>  3. "\((expr1, label2: expr2, label3: expr3))"
>> 
>> String(describing: (expr1, label2: expr2, label3: expr3))
>> 
>>  4. "\(expr1, label2: expr2, label3: expr3)"
>> 
>> String(describing: expr1, label2: expr2, label3: expr3)
>> 
>> I think I'm primarily concerned with the differences among cases 1, 3,
>> and 4, which are extremely minor.  3 and 4 differ by just a set of
>> parentheses, though that might be mitigated by the ${...} suggestion someone 
>> else posted.  The point of using string interpolation is to improve
>> readability, and I fear these cases make too many things look alike that
>> have very different meanings.  Using a common term like "format" calls
>> out what is being done.
> 
> We should look at this part of the problem as part of reconsidering the way 
> string interpolation works as a whole; there are other problems with our 
> current model, such as not being able to distinguish literal and non-literal 
> segments. I fear that even this:
> 
>> It's possible to produce terser versions of the syntax that don't suffer
>> from this problem by using a dedicated operator:
>> 
>>  "Column 1: \(n⛄(radix:16, width:8)) *** \(message)"
>>  "Something with leading zeroes: \(x⛄(fill: zero, width:8))"
> 
> has too many nested delimiters to be easily readable. If we had a string 
> interpolation protocol something like this:
> 
> protocol ExpressibleByStringInterpolation {
>   associatedtype LiteralSegment: ExpressibleByStringLiteral
>   associatedtype InterpolatedSegment
>   init()
> 
>   mutating func append(literalSegment: LiteralSegment)
>   mutating func append(interpolatedSegment: InterpolatedSegment)
> }
> 
> and "now you have \(n, radix: 16, width: 2) problems" in 'Thingy' context 
> desugared so that \() became a constructor call on the InterpolatedSegment 
> type:
> 
> {
>   var x = Thingy()
>   x.append(literalSegment: "now you have ")
>   x.append(interpolatedSegment: Thingy.InterpolatedSegment(n, radix: 16, 
> width: 2))
>   x.append(literalSegment: " problems")
>   return x
> }()
> 
> then String.InterpolatedSegment could be a struct that offers interesting 
> formatting initializers.
> 
> -Joe
> ___
> 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

Re: [swift-evolution] Strings in Swift 4

[Karl Wagner via swift-evolution]

Very nice improvements overall!


> To ease the pain of type mismatches, Substring should be a subtype of String 
> in the same way that Int is a subtype of Optional. This would give users 
> an implicit conversion from Substring to String, as well as the usual 
> implicit conversions such as [Substring] to [String] that other subtype 
> relationships receive.

As others have said, it would be nice for this to be more general. Perhaps we 
can have a special type or protocol, something like RecursiveSlice?

> A Substring passed where String is expected will be implicitly copied. When 
> compared to the “same type, copied storage” model, we have effectively 
> deferred the cost of copying from the point where a substring is created 
> until it must be converted to Stringfor use with an API.

Could noescape parameters/new memory model with borrowing make this more 
general? Again it seems very useful for all kinds of Collections.
> The “Empty Subscript”
> 
Empty subscript seems weird. IMO, it’s because of the asymmetry between 
subscripts and computed properties. I would favour a model which unifies 
computed properties and subscripts (e.g. computed properties could return 
“addressors” for in-place mutation).
Maybe this could be an “entireCollection”/“entireSlice" computed property?


> The goal is that Unicode exposes the underlying encoding and code units in 
> such a way that for types with a known representation (e.g. a 
> high-performance UTF8String) that information can be known at compile-time 
> and can be used to generate a single path, while still allowing types like 
> String that admit multiple representations to use runtime queries and 
> branches to fast path specializations.

Typo: “unicodeScalars" is in the protocol twice.

If I understand it, CodeUnits is the thing which should always be defined by 
conformers to Unicode, and UnicodeScalars and ExtendedASCII could have default 
implementations (for example, UTF8String/UTF16String/3rd party conformers will 
use those), and String might decide to return its native buffer (e.g. if 
Encoding.CodeUnit == UnicodeScalar).

I’m just wondering how difficult it would be for a 3rd-party type to conform to 
Unicode. If you’re developing a text editor, for example, it’s possible that 
you may need to implement your own String-like type with some optimised storage 
model and it would be nice to be able to use generic algorithms with them. I’m 
thinking that you will have some kind of backing buffer, and you will want to 
expose regions of that to clients as Strings so that they can render them for 
UI or search through them, etc, without introducing a copy just for the 
semantic understanding that this data region contains some text content.

I’ll need to examine the generic String idea more, but it’s certainly very 
interesting...

> Indexes


One thing which I think it critical is the ability to advance an index by a 
given number of codeUnits. I was writing some code which interfaced with the 
Cocoa NSTextStorage class, tagging parts of a string that a user was editing. 
If this was an Array, when the user inserts some elements before your stored 
indexes, those indexes become invalid but you can easily advance by the 
difference to efficiently have your indexes pointing to the same characters.

Currently, that’s impossible with String. If the user inserts a string at a 
given index, your old indexes may not even point to the start of a grapheme 
cluster any more, and advancing the index is needlessly costly. For example:

var characters = "This is a test".characters
assert(characters.count == 14)

// Store an index to something.
let endBeforePrepending = characters.endIndex

// Insert some characters somewhere.
let insertedCharacters = "[PREPENDED]".characters
assert(insertedCharacters.count == 11)
characters.replaceSubrange(characters.startIndex..

Re: [swift-evolution] Strings in Swift 4

[Joe Groff via swift-evolution]

> On Jan 20, 2017, at 8:28 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> 
> 
> Sent from my iPad
>> On Jan 20, 2017, at 5:48 AM, Jonathan Hull > > wrote:
>> 
>> Thanks for all the hard work!
>> 
>> Still digesting, but I definitely support the goal of string processing even 
>> better than Perl.  Some random thoughts:
>> 
>> • I also like the suggestion of implicit conversion from substring slices to 
>> strings based on a subtype relationship, since I keep running into that 
>> issue when trying to use array slices.  
> 
> Interesting.  Could you offer some examples?
> 
>> It would be nice to be able to specify that conversion behavior with other 
>> types that have a similar subtype relationship.
> 
> Indeed.
> 
>> • One thing that stood out was the interpolation format syntax, which seemed 
>> a bit convoluted and difficult to parse:
>>> "Something with leading zeroes: \(x.format(fill: zero, width:8))"
>> 
>> 
>> Have you considered treating the interpolation parenthesis more like the 
>> function call syntax?  It should be a familiar pattern and easily parseable 
>> to someone versed in other areas of swift:
>> 
>>   “Something with leading zeroes: \(x, fill: .zero, width: 8)"
> 
> Yes, we've considered it
> 
>  1. "\(f(expr1, label2: expr2, label3: expr3))" 
> 
> String(describing: f(expr1, label2: expr2, label3: expr3))
> 
>  2. "\(expr0 + expr1(label2: expr2, label3: expr3))"
> 
> String(describing: expr0 + expr1(label2: expr2, label3: expr3)
> 
>  3. "\((expr1, label2: expr2, label3: expr3))"
> 
> String(describing: (expr1, label2: expr2, label3: expr3))
> 
>  4. "\(expr1, label2: expr2, label3: expr3)"
> 
> String(describing: expr1, label2: expr2, label3: expr3)
> 
> I think I'm primarily concerned with the differences among cases 1, 3,
> and 4, which are extremely minor.  3 and 4 differ by just a set of
> parentheses, though that might be mitigated by the ${...} suggestion someone 
> else posted.  The point of using string interpolation is to improve
> readability, and I fear these cases make too many things look alike that
> have very different meanings.  Using a common term like "format" calls
> out what is being done.

We should look at this part of the problem as part of reconsidering the way 
string interpolation works as a whole; there are other problems with our 
current model, such as not being able to distinguish literal and non-literal 
segments. I fear that even this:

> It's possible to produce terser versions of the syntax that don't suffer
> from this problem by using a dedicated operator:
> 
>  "Column 1: \(n⛄(radix:16, width:8)) *** \(message)"
>  "Something with leading zeroes: \(x⛄(fill: zero, width:8))"

has too many nested delimiters to be easily readable. If we had a string 
interpolation protocol something like this:

protocol ExpressibleByStringInterpolation {
  associatedtype LiteralSegment: ExpressibleByStringLiteral
  associatedtype InterpolatedSegment
  init()

  mutating func append(literalSegment: LiteralSegment)
  mutating func append(interpolatedSegment: InterpolatedSegment)
}

and "now you have \(n, radix: 16, width: 2) problems" in 'Thingy' context 
desugared so that \() became a constructor call on the InterpolatedSegment type:

{
  var x = Thingy()
  x.append(literalSegment: "now you have ")
  x.append(interpolatedSegment: Thingy.InterpolatedSegment(n, radix: 16, width: 
2))
  x.append(literalSegment: " problems")
  return x
}()

then String.InterpolatedSegment could be a struct that offers interesting 
formatting initializers.

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

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

[Pierre Monod-Broca via swift-evolution]

The way I understand it, it's a bad idea to override == and != (or any infix 
operator) for Sub if Super has them and that's why the default implementation 
from Equatable only generates !=(Super, Super) and not !=(Sub, Sub) (and there 
is no ==(Sub, Sub) generated either).

And it's a bad idea because (without dynamic dispatch on both operands) it 
leads to unexpected behavior.

Considering :
```
func ==(lhs: Super, rhs: Super) -> Bool {
print("Super")
return true
}

func ==(lhs: Sub, rhs: Sub) -> Bool {
print("Sub")
return false
}

let a = Sub()
let b = Sub()
a == b // Sub
a as Super == b // Super
a == b as Super // Super
à as Super == b as Super // Super
```

One would compare the same objects and don't get the same result.

Instead you have to check the dynamic type yourself.


Pierre

> Le 20 janv. 2017 à 10:45, Francisco Javier Fernández Toro via swift-evolution 
>  a écrit :
> 
> 
> 
>> On Wed, Jan 18, 2017 at 6:58 PM, Tony Allevato  
>> wrote:
>> Ok, this actually does feel a bit strange. The behavior you're seeing seems 
>> to be a consequence of 
>> [SE-0091](https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md),
>>  but it looks like you're seeing different behavior than what I described in 
>> the "Class types and inheritance" section of that proposal.
>> 
>> If Sub has `==(Sub, Sub)` implemented as a *static* function, I just tried 
>> it and it's *ignored* (`==(Super, Super)` gets called instead), even when 
>> the two actual arguments are known to be statically of type Sub. I think 
>> this is because of the way that proposal was implemented: when it sees that 
>> `Sub` extends `Super`, which conforms to `Equatable`, it appears that it's 
>> only looking for static overloads of `==` that are satisfied at the *point 
>> of conformance*, which would be `==(Super, Super)` (because `Super` conforms 
>> to `Equatable where Self == Super`). The wording of the proposal makes this 
>> case: "Then, we say that we do not consider an operator function if it 
>> implements a protocol requirement, because the requirement is a 
>> generalization of all of the operator functions that satisfy that 
>> requirement."
>> 
>> Contrarily, if you provide `==(Sub, Sub)` as a global function instead of a 
>> static one, it *does* get called. I think in this case, the type checker 
>> gets the whole set of candidate operators (which, unlike above, includes the 
>> global `==(Sub, Sub)`), and it gets used because it's a more specific match?
>> 
> 
> FWIW, I've just changed both `==` functions to make them global, the the 
> outcome is still the same, its using `==(Super,Super)` to resolve `!=(Sub,Sub)
>  
>> Can someone from the core team chime in and say whether this is intentional 
>> behavior? It feels wrong that simply changing the location where the 
>> operator is defined would change the behavior like this.
>> 
>> FWIW, to avoid these sharp edges, there's no need to implement `==` for 
>> subtypes; since you have to use an overridable `equals` method anyway, just 
>> have the base type implement `==` to delegate to it, and then have subtypes 
>> override `equals` alone.
>> 
>> 
>>> On Wed, Jan 18, 2017 at 9:36 AM Francisco Javier Fernández Toro 
>>>  wrote:
>>> Yeah guys, you are right, my code is busted, I was trying to point 
>>> something different out:
>>> 
>>> The next code is showing the possible issue. In theory to make a class 
>>> Equatable, you just have to mark it with the Equatable protocol and 
>>> implement `==` as a static function or as a global one.
>>> 
>>> If you don't override the equal method and you just invoke your super class 
>>> equality method you'll get something like this: 
>>> 
>>> ```
>>> class Superclass : Equatable {
>>> let foo: Int
>>> 
>>> init(foo: Int) { self.foo = foo }
>>> 
>>> func equal(to: Superclass) -> Bool {
>>> return foo == to.foo
>>> }
>>> 
>>> static func == (lhs: Superclass, rhs: Superclass) -> Bool {
>>> return lhs.equal(to: rhs)
>>> }
>>> }
>>> 
>>> class Subclass: Superclass {
>>> let bar: Int
>>> init(foo: Int, bar: Int) {
>>> self.bar = bar
>>> super.init(foo: foo)
>>> }
>>> 
>>> func equal(to: Subclass) -> Bool {
>>> return bar == to.bar && super.equal(to: to)
>>> }
>>> 
>>> static func == (lhs: Subclass, rhs: Subclass) -> Bool {
>>> return lhs.equal(to: rhs)
>>> }
>>> }
>>> 
>>> class SubclassWithDifferentOperator: Subclass {
>>> static func != (lhs: SubclassWithDifferentOperator, rhs: 
>>> SubclassWithDifferentOperator) -> Bool {
>>> return !(lhs.equal(to: rhs))
>>> }
>>> }
>>> 
>>> let a = Subclass(foo: 1, bar: 1)
>>> let b = Subclass(foo: 1, bar: 2)
>>> 
>>> (a == b) != (a != b) // Prints: false, not expected
>>> 
>>> let x = SubclassWithDifferentOperator(foo: 1, bar: 1)
>>> let y 

Re: [swift-evolution] Strings in Swift 4

[Joe Groff via swift-evolution]

Jordan points out that the generalized slicing syntax stomps on '...x' and 
'x...', which would be somewhat obvious candidates for variadic splatting if 
that ever becomes a thing. Now, variadics are a much more esoteric feature and 
slicing is much more important to day-to-day programming, so this isn't the end 
of the world IMO, but it is something we'd be giving up.

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

[swift-evolution] [Review] SE-0148 Generic Subscripts

[Krzysztof Zabłocki via swift-evolution]

• What is your evaluation of the proposal?

 Well written, concise and to the point. +1 on support for default values as 
well.


• Is the problem being addressed significant enough to warrant a change to 
Swift?

 Absolutely, not to mention is part of our Generic Manifesto 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts
 and was raised before by Radek Pietruszewski on 
https://bugs.swift.org/browse/SR-115


• Does this proposal fit well with the feel and direction of Swift?

 Yes, this fits very well with how generic code is written right now.


• How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

 Quick reading

Regards,
Krzysztof Zabłocki
http://merowing.info
http://twitter.com/merowing_
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] HTML rendering output (was: Strings in Swift 4)

[David Waite via swift-evolution]

With the current model, I’d make a first pass of this sort of functionality by 
doing:

1. Define a HtmlEncoded wrapping struct that indicated a value was meant to be 
safe to output directly, rather than be encoded. This would make encoding safe 
by default (opt out)
2. HTML content built via string interpolation would escape any data input not 
wrapped in a HtmlEncoded struct.
3. Define functions for the common tags which output nested html data, rather 
than having people write the tags themselves.

With all that, your code would probably be:

let title = "boom();"
result.render(h1(title)); // outputs 'script>boom();/script>'

4. (maybe) HtmlEncoded is ExpressibleByStringInterpolation, so that

var username = “boom();”
var encoded:HtmlEncoded = “Hello, \(username)”
print(encoded) //  ‘Hello, script>boom();/script>'

This is somewhat analogous to Rails 3’s String.html_safe functionality, and 
avoids interpreting string safety based on a string being a literal .

-DW

> On Jan 20, 2017, at 9:27 AM, Gwendal Roué via swift-evolution 
>  wrote:
> 
>> One ask - make string interpolation great again?
> 
> I have a dream, that ExpressibleByStringInterpolation would allow to 
> distinguish literal segments and embedded inputs.
> 
> Today, the documentation of this protocol [1] says:
> 
>   "One cookie: $\(price), \(number) cookies: $\(price * number)."
>   // <=>
>   let message = String(stringInterpolation:
>   String(stringInterpolationSegment: "One cookie: $"),
>   String(stringInterpolationSegment: price),
>   String(stringInterpolationSegment: ", "),
>   String(stringInterpolationSegment: number),
>   String(stringInterpolationSegment: " cookies: $"),
>   String(stringInterpolationSegment: price * number),
>   String(stringInterpolationSegment: "."))
> 
> This means that ExpressibleByStringInterpolation can't distinguish "foo" from 
> `bar` in "foo\(bar)".
> 
> If this distinction were possible, some nice features could emerge, such as 
> context-sensitive escaping:
> 
>   // func render(_ html: HTML)
>   let title = "boom();"
>   render("\(title)") // escapes input
>   
>   // func query(_ sql: SQL)
>   let name = "Robert'); DROP TABLE students; --"
>   query("SELECT * FROM students WHERE name = \(name)") // avoids SQL 
> injection
> 
> Ideally, a solution for multi-line literals (for strings and interpolated 
> strings) would be found, too.
> 
> I wish the manifesto would address these topics as well :-)
> 
> Regards,
> Gwendal Roué
> 
> [1] 
> https://developer.apple.com/reference/swift/expressiblebystringinterpolation
> 
> ___
> 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

Re: [swift-evolution] Strings in Swift 4

[Georgios Moschovitis via swift-evolution]

> I think the \( … ) is just as readable as ${ … }. Actually, I would have been 
> OK with \{ … } but I think that ship has sailed because of the existing code 
> base using \( … ).

Totally agree!

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

Re: [swift-evolution] Strings in Swift 4

[Georgios Moschovitis via swift-evolution]

> 
> Which for my preference makes the syntax feel more readable, avoids the 
> "double ))" in terms of string interpolation termination and function 
> termination points. And if that's not enough brings the "feel" of the 
> language to be scriptable in nature common in bash, sh, zsh and co.. 
> scripting interpreters and has been adopted as part of ES6 interpolation 
> syntax[1]. 

-10

I find the use of `\(..)` for interpolation one of the most tasteful design 
additions in Swift.
Absolutely no need to change it!


George 

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

Re: [swift-evolution] Strings in Swift 4

[Jeremy Pereira via swift-evolution]

> On 20 Jan 2017, at 11:55, Maxim Veksler  wrote:
> 
> Please see discussion inline.
> 
> On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira 
>  wrote:
> 
> > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution 
> >  wrote:
> >
> > One ask - make string interpolation great again?
> >
> > Taking from examples supplied at 
> > https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation
> >
> > "Column 1: \(n.format(radix:16, width:8)) *** \(message)"
> >
> > Why not use:
> >
> > "Column 1: ${n.format(radix:16, width:8)} *** $message"
> >
> > Which for my preference makes the syntax feel more readable, avoids the 
> > "double ))" in terms of string interpolation termination and function 
> > termination points. And if that's not enough brings the "feel" of the 
> > language to be scriptable in nature common in bash, sh, zsh and co.. 
> > scripting interpreters and has been adopted as part of ES6 interpolation 
> > syntax[1].
> >
> 
> This idea came up once before on Swift Evo. The arguments against are:
> 
> 1. Swift already has an “escape” character for inserting non literal stuff 
> into strings - the “\” character. Either you have two - increasing complexity 
> for both the developer and the Swift compiler’s tokeniser - or you have to 
> change everything that uses “\” to use $ e.g. $t $n instead of \t \n.
> 
> 
> I would claim that this serves as an reinforcement of making the 
> distinctions. "\t" is not the same behavior as "\(someVariable)" both 
> conceptually - I think there is a clear distinction between inserting a 
> "constant symbol" to inserting "the string content of a variable" and 
> semantically - While you would use \t to insert a tab you are mandated by the 
> semantics to use \( .. ) to insert the contents of a variable.

I agree there is a difference. \t inserts a tab at compile time whereas \( … ) 
inserts the expression converted to a string at run time. However, I don’t 
agree that the distinction is sufficient to require a different character to 
introduce the non literal bit. I presume you are quite comfortable with

let a = 3 + 4
let b = x + y

both using the + symbol even though the former is evaluated entirely by the 
compiler.


>  
> 2. The dollar sign is a disastrous symbol to use for an special character, 
> especially in the USA where it is commonly used to signify the local 
> currency. Yes, I know it is used for interpolation in Perl, Shell and 
> Javascript and others,  but “this other language I like does X, therefore 
> Swift should do X” is not a good argument.
> 
> 
> Please name concrete examples?

Of what? Of disasters that have arisen through using the $ character? I admit 
the adjective was a bit over the top, “bad” would have been more accurate.

> I would believe that the case for $variableName to be rare enough to justify 
> expecting the developer to make an escape claim with \$variableName, likewise 
> for ${variableName}, if expected output is plain text I wouldn't imagine this 
> "\$\{variableName\}" to be a far reaching expectation.

Well thats seems quite a lot more ugly than the status quo to me.

> 
> The use of $ symbol is more reaching[1], and is being adopted constantly as 
> the selected patten for even recent developments as Facebook's GraphQL query 
> syntax[2] which to the best of my knowledge was invented in US. 

I wish they wouldn’t. 

> 
> 3. There is already quite a lot of code that uses \( … ) for interpolation, 
> this would be a massive breaking change.
> 
> 
> True, but going forward that would enable a "better readable" code for larger 
> number of users. Additionally I would suggest that automatic conversion using 
> Swift Migration Assistant should be possible.


I disagree. I think the \( … ) is just as readable as ${ … }. Actually, I would 
have been OK with \{ … } but I think that ship has sailed because of the 
existing code base using \( … ).

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

Re: [swift-evolution] Strings in Swift 4

[Tony Allevato via swift-evolution]

I'm excited to see this taking shape. Thanks for all the hard work putting
this together!

A few random thoughts I had while reading it:

* You talk about an integer `codeUnitOffset` property for indexes. Since
the current String implementation can switch between backing storage of
ASCII or UTF-16 depending on the content of the string and how it's
obtained, presumably this means that integer is not necessarily the same as
the offset into the buffer, correct? (In other words, for a UTF-16-stored
string, you would have to multiply it by 2.)

* You discuss the possibility of exposing some String methods, like
`uppercase()`, on Character. Since Swift abstracts away the encoding, it
seems like Characters are essentially Strings that are enforced at runtime
(and sometimes at compile time, in the case of initialization from
literals) to contain exactly 1 grapheme cluster. Given that, I think it
would be worthwhile for Character to support *any* method on String that
would be sensical to operate on a single character—case transformations
(though perhaps not titlecase?), accessing its UTF-8 or UTF-16 views, and
so forth. I would ask whether it makes sense to have a shared protocol
between Character and String that defines those methods, but I'll defer on
that because it feels like it would be a "bag of methods" rather than
semantically meaningful.

On that same point, if I have a lightweight (<= 63 bit) Character, many of
those operations can only currently be performed by constructing a String
from it, which incurs a time and heap allocation penalty. (And indeed,
there are TODOs in the code base to avoid doing such things internally, in
the case of Character comparisons.) Which leads me to my next thought,
since I've been doing a lot with Swift String performance lately...

* Currently, Character and String have divergent internal implementations.
A Character can be "small" (<= 63 bits in UTF-8 packed into an integer) or
"large" (> 63 bits with a heap-allocated buffer). Strings are just backed
by a heap-allocated buffer. In this write-up, you say "Many strings are
short enough to store in 64 bits"—not just characters. If that's the case,
can those optimizations be lowered into _StringCore (or its new-world
counterpart), which would allow both Characters *and* small Strings to reap
the benefits of the more efficient implementation? This would let
Characters get implementations of common methods like `uppercase()` for
free, and there would be a zero-cost conversion from Characters to Strings.
The only real difference between the types would be the APIs they vend, the
semantic concept that they represent to users, and validation.

* The talk about implicit conversions between Substring and String bums me
out, even though I see the importance of it in this context and know that
it outweighs the alternatives. Given that the Swift team seems to prefer
explicit to implicit conversions in general, I would hope that if they feel
it's important enough to make a special case for the standard library, it
could be a language feature that you'd consider making available to anyone.


On Fri, Jan 20, 2017 at 7:35 AM Ben Cohen via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 19, 2017, at 10:42 PM, Jose Cheyo Jimenez 
> wrote:
>
> I just have one concern about the slice of a string being called
> Substring. Why not StringSlice? The word substring can mean so many things,
> specially in cocoa.
>
>
> This idea has a lot of merit, as does the option of not giving them a
> top-level name at all e.g. they could be String.Slice or
> String.SubSequence. It would underscore that they really aren’t meant to be
> used except as the result of a slicing operation or to efficiently pass a
> slice. OTOH, Substring is a term of art so can help with clarity.
>
>
> ___
> 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

Re: [swift-evolution] Strings in Swift 4

[Ben Cohen via swift-evolution]

> On Jan 20, 2017, at 8:04 AM, Ole Begemann  wrote:
> 
>> The downside of having two types is the inconvenience of sometimes having
>> a
>> `Substring` when you need a `String`, and vice-versa. It is likely this
>> would
>> be a significantly bigger problem than with `Array` and `ArraySlice`, as
>> slicing of `String` is such a common operation. It is especially relevant
>> to
>> existing code that assumes `String` is the currency type.
> 
> I'm not familiar with the term "currency type" that appears several
> times in the document. Could you clarify what it means? Googling it
> proved difficult because all results are about the "money" meaning of
> "currency".

Yes, that is a bit jargony.

We mean it as in a “common currency” that everyone uses for exchange. That is, 
what everyone should use to pass strings around, between API boundaries etc. 
The goal is for people not to have to think “hmm, what kind of string type 
should I use here”. If you are not sure, String is always a reasonable default.


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

Re: [swift-evolution] Strings in Swift 4

[Gwendal Roué via swift-evolution]

> One ask - make string interpolation great again?

I have a dream, that ExpressibleByStringInterpolation would allow to 
distinguish literal segments and embedded inputs.

Today, the documentation of this protocol [1] says:

"One cookie: $\(price), \(number) cookies: $\(price * number)."
// <=>
let message = String(stringInterpolation:
String(stringInterpolationSegment: "One cookie: $"),
String(stringInterpolationSegment: price),
String(stringInterpolationSegment: ", "),
String(stringInterpolationSegment: number),
String(stringInterpolationSegment: " cookies: $"),
String(stringInterpolationSegment: price * number),
String(stringInterpolationSegment: "."))

This means that ExpressibleByStringInterpolation can't distinguish "foo" from 
`bar` in "foo\(bar)".

If this distinction were possible, some nice features could emerge, such as 
context-sensitive escaping:

// func render(_ html: HTML)
let title = "boom();"
render("\(title)") // escapes input

// func query(_ sql: SQL)
let name = "Robert'); DROP TABLE students; --"
query("SELECT * FROM students WHERE name = \(name)") // avoids SQL 
injection

Ideally, a solution for multi-line literals (for strings and interpolated 
strings) would be found, too.

I wish the manifesto would address these topics as well :-)

Regards,
Gwendal Roué

[1] https://developer.apple.com/reference/swift/expressiblebystringinterpolation

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

Re: [swift-evolution] Strings in Swift 4

[Ole Begemann via swift-evolution]

> The downside of having two types is the inconvenience of sometimes having
> a
> `Substring` when you need a `String`, and vice-versa. It is likely this
> would
> be a significantly bigger problem than with `Array` and `ArraySlice`, as
> slicing of `String` is such a common operation. It is especially relevant
> to
> existing code that assumes `String` is the currency type.

I'm not familiar with the term "currency type" that appears several
times in the document. Could you clarify what it means? Googling it
proved difficult because all results are about the "money" meaning of
"currency".
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

Sent from my iPad

> On Jan 19, 2017, at 8:20 PM, Xiaodi Wu  wrote:
> 
> Clearly too big to digest in one take. Some initial thoughts:
> 
> * Not sure about the wisdom of the ad-hoc Substring : String compiler magic. 
> It seems that whatever needs overcoming here would be equally relevant for 
> ArraySlice.

We have mixed feelings about it as well, and you make a good point about 
ArraySlice.  I'm not convinced trafficking in slices is going to be as 
important for Array as it is for String, though.

> It would be more design work, but perhaps not terribly more implementation 
> work, to have a magical protocol that allows the compiler to apply a similar 
> magic to conforming types (e.g. a `ImplicitlyConvertibleSlice` protocol with 
> an associated type, to which ArraySlice and String could both conform).

It's not just about slices.  There are other subtype relationships we'll want 
in the language eventually anyway.  Int8:Int16, for example.  We don't t

> Alternatively, perhaps all of this is not truly necessary for sufficient 
> ergonomics.

Personally I would be happy to try the design without the implicit conversion 
first, but there are legitimate concerns about forcing users to write 
String(someSubstring) and the manifesto needs to at least offer a solid plan in 
place for addressing it.

> * A requirement to transcode UTF-8 strings to UTF-16 for storage 
> seems...inefficient?

To be clear, nobody's suggesting that you can't store a UTF8String, only that 
it may be necessary to restrict the encodings that can be stored in the 
currency type "String."
 
> Why any hesitation at all to expose UTF-8-encoded code units as UInt16? Sure, 
> there are going to be unused bits, but so what?

We're still exploring the design space.  That idea is relatively fresh and I 
haven't convinced myself that it is both efficient and ergonomic.  But it's 
promising.

> If I understand it correctly, it's only the concrete type exposed on String 
> for code units that's in play here; the backing representations themselves 
> can use whatever is most efficient.

Yes.

> So, why _not_ support UTF-32 and expose all code units as UInt32? Isn't that 
> exactly paralleling the design for the extendedASCII view, where users get 
> ASCII characters back as UInt32 and encoding-specific code units as such as 
> well?

Yes, there's a definite parallel.

> * Are the backing representations for String also the same types that can be 
> exposed statically (as in the mentioned `NFCNormalizedUTF16String`)?

Roughly.  I think we want at least the following backing representations for 
String:

1. The two compressed representations used by Cocoa "tagged pointer" strings
2. A third "tagged pointer" representation that stores 63 bits of UTF-16 (so 
arbitrary UnicodeScalars and most Characters can be stored efficiently)
3. A known Latin-1 backing store that we can fast-path
4. A known UTF-16 backing store
5. A type-erased arbitrary (or nearly-arbitrary, if we have to accept a UTF16 
subset restriction) instance of Unicode

It's possible that some of the representations in the range 3...5 can be 
collapsed into one.

> * Why `withCString` with a closure instead of just `cString` returning 
> [CChar]? Particularly if the backing store isn't UTF8, isn't the C string 
> going to have to be a newly allocated buffer anyway?

Not if the backing store is Latin-1, which will be very common.
Also not if the string is short and can be transcoded into stack-based storage, 
which will also be common.

> Personally, I find the current `utf8CString` to be quite convenient :P

All these string types should bridge seamlessly to char*.  Isn't that enough 
for the super-lightweight use case?

>> On Thu, Jan 19, 2017 at 8:56 PM, Ben Cohen via swift-evolution 
>>  wrote:
>> Hi all,
>> 
>> Below is our take on a design manifesto for Strings in Swift 4 and beyond.
>> 
>> Probably best read in rendered markdown on GitHub:
>> https://github.com/apple/swift/blob/master/docs/StringManifesto.md
>> 
>> We’re eager to hear everyone’s thoughts.
>> 
>> Regards,
>> Ben and Dave
>> 
>> 
>> # String Processing For Swift 4
>> 
>> * Authors: [Dave Abrahams](https://github.com/dabrahams), [Ben 
>> Cohen](https://github.com/airspeedswift)
>> 
>> The goal of re-evaluating Strings for Swift 4 has been fairly ill-defined 
>> thus
>> far, with just this short blurb in the
>> [list of 
>> goals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html):
>> 
>> > **String re-evaluation**: String is one of the most important fundamental
>> > types in the language.  The standard library leads have numerous ideas of 
>> > how
>> > to improve the programming model for it, without jeopardizing the goals of
>> > providing a unicode-correct-by-default model.  Our goal is to be better at
>> > string processing than Perl!
>> 
>> For Swift 4 and beyond we want to improve three dimensions of text 
>> processing:
>> 

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

Sent from my iPad

> On Jan 19, 2017, at 6:07 PM, Ben Cohen  wrote:
> 
> The defaults for case-, diacritic-, and width-insensitivity are different for 
> localized operations than for non-localized operations, so for example a 
> localized sort should be case-insensitive by default, and a non-localized 
> sort should be case-sensitive by default.

Sorry, a correction already:

Both localized- and non-localized sorts should be case- and diacritic-sensitive 
by default. Localized searches should be case- and diacritic-insensitive by 
default.

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

Re: [swift-evolution] Strings in Swift 4

[Ben Cohen via swift-evolution]

> On Jan 19, 2017, at 10:42 PM, Jose Cheyo Jimenez  wrote:
> 
> I just have one concern about the slice of a string being called Substring. 
> Why not StringSlice? The word substring can mean so many things, specially in 
> cocoa. 

This idea has a lot of merit, as does the option of not giving them a top-level 
name at all e.g. they could be String.Slice or String.SubSequence. It would 
underscore that they really aren’t meant to be used except as the result of a 
slicing operation or to efficiently pass a slice. OTOH, Substring is a term of 
art so can help with clarity.


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

Re: [swift-evolution] Strings in Swift 4

[Saagar Jha via swift-evolution]

Found it: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021548.html
 


Saagar Jha

> On Jan 20, 2017, at 4:10 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
>> 
>> On Jan 20, 2017, at 12:55 PM, Maxim Veksler via swift-evolution 
>> > wrote:
>> 
>> Please see discussion inline.
>> 
>> On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira 
>> > 
>> wrote:
>> 
>> > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution 
>> > > wrote:
>> >
>> > One ask - make string interpolation great again?
>> >
>> > Taking from examples supplied at 
>> > https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation
>> >  
>> > 
>> >
>> > "Column 1: \(n.format(radix:16, width:8)) *** \(message)"
>> >
>> > Why not use:
>> >
>> > "Column 1: ${n.format(radix:16, width:8)} *** $message"
>> >
>> > Which for my preference makes the syntax feel more readable, avoids the 
>> > "double ))" in terms of string interpolation termination and function 
>> > termination points. And if that's not enough brings the "feel" of the 
>> > language to be scriptable in nature common in bash, sh, zsh and co.. 
>> > scripting interpreters and has been adopted as part of ES6 interpolation 
>> > syntax[1].
>> >
>> 
>> This idea came up once before on Swift Evo. The arguments against are:
>> 
>> 1. Swift already has an “escape” character for inserting non literal stuff 
>> into strings - the “\” character. Either you have two - increasing 
>> complexity for both the developer and the Swift compiler’s tokeniser - or 
>> you have to change everything that uses “\” to use $ e.g. $t $n instead of 
>> \t \n.
>> 
>> 
>> I would claim that this serves as an reinforcement of making the 
>> distinctions. "\t" is not the same behavior as "\(someVariable)" both 
>> conceptually - I think there is a clear distinction between inserting a 
>> "constant symbol" to inserting "the string content of a variable" and 
>> semantically - While you would use \t to insert a tab you are mandated by 
>> the semantics to use \( .. ) to insert the contents of a variable.
> 
> Hi Maxim,
> 
> there was quite a discussion on this matter a few months ago - I can't find 
> the thread right now, but the consensus of majority here seemed to be that 
> the current status is desirable by most and that it contains some unified 
> philosophy over anything that will "not print as typed". I believe that this 
> is something that has been discussed here several times - keep in mind Swift 
> 4 is supposed to be as much backward compatible as possible with breaking 
> changes requiring severe justification - there is unlikely to be one for this 
> other than "I like it better this way".
> 
>>  
>> 2. The dollar sign is a disastrous symbol to use for an special character, 
>> especially in the USA where it is commonly used to signify the local 
>> currency. Yes, I know it is used for interpolation in Perl, Shell and 
>> Javascript and others,  but “this other language I like does X, therefore 
>> Swift should do X” is not a good argument.
>> 
>> 
>> Please name concrete examples? I would believe that the case for 
>> $variableName to be rare enough to justify expecting the developer to make 
>> an escape claim with \$variableName, likewise for ${variableName}, if 
>> expected output is plain text I wouldn't imagine this "\$\{variableName\}" 
>> to be a far reaching expectation.
>> 
>> The use of $ symbol is more reaching[1], and is being adopted constantly as 
>> the selected patten for even recent developments as Facebook's GraphQL query 
>> syntax[2] which to the best of my knowledge was invented in US. 
>> 
>> 3. There is already quite a lot of code that uses \( … ) for interpolation, 
>> this would be a massive breaking change.
>> 
>> 
>> True, but going forward that would enable a "better readable" code for 
>> larger number of users. Additionally I would suggest that automatic 
>> conversion using Swift Migration Assistant should be possible.
>> 
>> 
>> ___
>> 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 
> 
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

Sent from my iPad

> On Jan 19, 2017, at 8:18 PM, Ben Cohen  wrote:
> 
> 
>> On Jan 19, 2017, at 19:38, David Sweeris  wrote:
>> 
>> Regarding substrings... Instead of having separate `ArraySlice` and 
>> `Substring` types, what about having just one type, `Slice`, 
>> for anything which shares memory? Seems like it'd be easier for users who'd 
>> only have to worry about shared storage for one type, and for stdlib authors 
>> who'd only have to write it once.
> 
> Collections already do get a default SubSequence implementation of 
> Slice that is essentially like just that. 
> 
> The reason types like Array and String have their own is to customize it with 
> more than the default behavior. For example, ArraySlice provides 
> .withUnsafeBufferPointer  method just like an Array does. Substring would 
> need all the features String provides.
> 
> Now, once we get conditional conformance, we could use that to maybe increase 
> sharing, for example we could create a protocol for types backed by 
> contiguous memory that provided withUnsafeEtc, and then use conditional 
> conformance to add those features to Slice when the Base has them.

We don't need conditional conformance in order to replace ArraySlice with 
MutableRangeReplaceableRandomAccessSlice, but to spell that Slice 
or generalize withUnsafeXXX to a ContiguouslyStored without adding another in 
our already-too-large menagerie of slice types, we would.

Substring is different, though: we want to specialize its storage to be able to 
store code units inline, without using any dynamic memory, so it would need to 
have a different type from the generic Slice.

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

Re: [swift-evolution] Strings in Swift 4

[Dave Abrahams via swift-evolution]

Sent from my iPad

> On Jan 19, 2017, at 8:13 PM, David Sweeris  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jan 19, 2017, at 20:56, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> Below is our take on a design manifesto for Strings in Swift 4 and beyond.
>> 
>> Probably best read in rendered markdown on GitHub:
>> https://github.com/apple/swift/blob/master/docs/StringManifesto.md
>> 
>> We’re eager to hear everyone’s thoughts.
>> 
>> Regards,
>> Ben and Dave
> 
> An enthusiastic +1
> 
> A couple more quick thoughts...
> 
> 1) Is it just me, or is explicitly putting some of the "higher level" 
> functionality in Foundation instead of stdlib kinda reminiscent of MVC? I 
> guess UIKit/Cocoa would be the "View" part.

Might just be you ;-)

> 2) I like the idea of making String generic over its encoding... Would we 
> need to nail down the hypothetical type promotion system for that to work, or 
> can it all be handled internally?

If you're implicitly asking what the type of s1 + s2 is when they have 
different encodings,
I don't think we need a type promotion system to handle that.  Unlike with 
fixed-width integers, there is a family of maximally-expressive encodings that 
can be used for the result of any operation whose result would otherwise be in 
doubt without any serious loss of performance.  I would probably just go with 
the currency type, "String" for these cases.

Cheers,
--
Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[Ole Begemann via swift-evolution]

extension Unicode {
 // An example of the option language in declaration context,
 // with nil defaults indicating unspecified, so defaults can be
 // driven by the presence/absence of a specific Locale
 func frobnicated(
   case caseSensitivity: StringSensitivity? = nil,
   diacritic diacriticSensitivity: StringSensitivity? = nil,
   width widthSensitivity: StringSensitivity? = nil,
   in locale: Locale? = nil
 ) -> Self { ... }
}
```


Any reason why Locale is defaulted to nil, instead of currentLocale? It
seems more useful to me.


The reason is given in the text above the code sample: "The defaults for 
case-, diacritic-, and width-insensitivity are different for localized 
operations than for non-localized operations, so for example a localized 
sort should be case-insensitive by default, and a non-localized sort 
should be case-sensitive by default."


So the API would need to distinguish between "current locale" and "no 
locale" (i.e. use the non-localized algorithm).



Will String also conform to SequenceType? I’ve seen many users (coming
from other languages) confused that they can’t “just” loop over a
String’s characters.


Collection refines Sequence, so all collections are sequences. This 
would also be true for String. So yes, you could do `for char in string` 
again.


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

Re: [swift-evolution] Strings in Swift 4

[Charlie Monroe via swift-evolution]

> On Jan 20, 2017, at 2:48 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> ...
> 
> • One thing that stood out was the interpolation format syntax, which seemed 
> a bit convoluted and difficult to parse:
>> "Something with leading zeroes: \(x.format(fill: zero, width:8))"
> 
> 
> Have you considered treating the interpolation parenthesis more like the 
> function call syntax?  It should be a familiar pattern and easily parseable 
> to someone versed in other areas of swift:
> 
>   “Something with leading zeroes: \(x, fill: .zero, width: 8)"

+1 - really like this. If we could make this customizable, it would be great. 
E.g. if x has a method called "format" that takes some arguments and returns 
String...

struct Foo {
func format(withLocale locale: Locale?) -> String { ... }
}

let foo = Foo()
"\(foo, locale: Locale.current)"

> 
> 
> I think that should work for the common cases (e.g. padding, truncating, and 
> alignment), with string-returning methods on the type (or even formatting 
> objects ala NSNumberFormatter) being used for more exotic formatting needs 
> (e.g. outputting a number as Hex instead of Decimal)
> 
> • Have you considered having an explicit .machine locale which means that the 
> function should treat the string as machine readable? (as opposed to the lack 
> of a locale)
> 
> • I almost feel like the machine readableness vs human readableness of a 
> string is information that should travel with the string itself. It would be 
> nice to have an extremely terse way to specify that a string is localizable 
> (strawman syntax below), and that might also classify the string as human 
> readable.
> 
>   let myLocalizedStr = $”This is localizable” //This gets used as the 
> comment in the localization file
> 
> 
> • Looking forward to RegEx literals!
> 
> Thanks,
> Jon
> 
> 
>> On Jan 19, 2017, at 6:56 PM, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> Below is our take on a design manifesto for Strings in Swift 4 and beyond.
>> 
>> Probably best read in rendered markdown on GitHub:
>> https://github.com/apple/swift/blob/master/docs/StringManifesto.md
>> 
>> We’re eager to hear everyone’s thoughts.
>> 
>> Regards,
>> Ben and Dave
>> 
>> 
>> # String Processing For Swift 4
>> 
>> * Authors: [Dave Abrahams](https://github.com/dabrahams), [Ben 
>> Cohen](https://github.com/airspeedswift)
>> 
>> The goal of re-evaluating Strings for Swift 4 has been fairly ill-defined 
>> thus
>> far, with just this short blurb in the
>> [list of 
>> goals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html):
>> 
>>> **String re-evaluation**: String is one of the most important fundamental
>>> types in the language.  The standard library leads have numerous ideas of 
>>> how
>>> to improve the programming model for it, without jeopardizing the goals of
>>> providing a unicode-correct-by-default model.  Our goal is to be better at
>>> string processing than Perl!
>> 
>> For Swift 4 and beyond we want to improve three dimensions of text 
>> processing:
>> 
>> 1. Ergonomics
>> 2. Correctness
>> 3. Performance
>> 
>> This document is meant to both provide a sense of the long-term vision 
>> (including undecided issues and possible approaches), and to define the 
>> scope of
>> work that could be done in the Swift 4 timeframe.
>> 
>> ## General Principles
>> 
>> ### Ergonomics
>> 
>> It's worth noting that ergonomics and correctness are mutually-reinforcing.  
>> An
>> API that is easy to use—but incorrectly—cannot be considered an ergonomic
>> success.  Conversely, an API that's simply hard to use is also hard to use
>> correctly.  Acheiving optimal performance without compromising ergonomics or
>> correctness is a greater challenge.
>> 
>> Consistency with the Swift language and idioms is also important for
>> ergonomics. There are several places both in the standard library and in the
>> foundation additions to `String` where patterns and practices found elsewhere
>> could be applied to improve usability and familiarity.
>> 
>> ### API Surface Area
>> 
>> Primary data types such as `String` should have APIs that are easily 
>> understood
>> given a signature and a one-line summary.  Today, `String` fails that test.  
>> As
>> you can see, the Standard Library and Foundation both contribute 
>> significantly to
>> its overall complexity.
>> 
>> **Method Arity** | **Standard Library** | **Foundation**
>> ---|:---:|:---:
>> 0: `ƒ()` | 5 | 7
>> 1: `ƒ(:)` | 19 | 48
>> 2: `ƒ(::)` | 13 | 19
>> 3: `ƒ(:::)` | 5 | 11
>> 4: `ƒ()` | 1 | 7
>> 5: `ƒ(:)` | - | 2
>> 6: `ƒ(::)` | - | 1
>> 
>> **API Kind** | **Standard Library** | **Foundation**
>> ---|:---:|:---:
>> `init` | 41 | 18
>> `func` | 42 | 55
>> `subscript` | 9 | 0
>> `var` | 26 | 14
>> 
>> **Total: 205 APIs**
>> 
>> By contrast, `Int` has 80 APIs, none with more than two parameters.[0] 
>> String processing is complex enough; 

Re: [swift-evolution] Strings in Swift 4

[Jonathan Hull via swift-evolution]

Thanks for all the hard work!

Still digesting, but I definitely support the goal of string processing even 
better than Perl.  Some random thoughts:

• I also like the suggestion of implicit conversion from substring slices to 
strings based on a subtype relationship, since I keep running into that issue 
when trying to use array slices.  It would be nice to be able to specify that 
conversion behavior with other types that have a similar subtype relationship.

• One thing that stood out was the interpolation format syntax, which seemed a 
bit convoluted and difficult to parse:
> "Something with leading zeroes: \(x.format(fill: zero, width:8))"


Have you considered treating the interpolation parenthesis more like the 
function call syntax?  It should be a familiar pattern and easily parseable to 
someone versed in other areas of swift:

“Something with leading zeroes: \(x, fill: .zero, width: 8)"


I think that should work for the common cases (e.g. padding, truncating, and 
alignment), with string-returning methods on the type (or even formatting 
objects ala NSNumberFormatter) being used for more exotic formatting needs 
(e.g. outputting a number as Hex instead of Decimal)

• Have you considered having an explicit .machine locale which means that the 
function should treat the string as machine readable? (as opposed to the lack 
of a locale)

• I almost feel like the machine readableness vs human readableness of a string 
is information that should travel with the string itself. It would be nice to 
have an extremely terse way to specify that a string is localizable (strawman 
syntax below), and that might also classify the string as human readable.

let myLocalizedStr = $”This is localizable” //This gets used as the 
comment in the localization file


• Looking forward to RegEx literals!

Thanks,
Jon


> On Jan 19, 2017, at 6:56 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> Below is our take on a design manifesto for Strings in Swift 4 and beyond.
> 
> Probably best read in rendered markdown on GitHub:
> https://github.com/apple/swift/blob/master/docs/StringManifesto.md
> 
> We’re eager to hear everyone’s thoughts.
> 
> Regards,
> Ben and Dave
> 
> 
> # String Processing For Swift 4
> 
> * Authors: [Dave Abrahams](https://github.com/dabrahams), [Ben 
> Cohen](https://github.com/airspeedswift)
> 
> The goal of re-evaluating Strings for Swift 4 has been fairly ill-defined thus
> far, with just this short blurb in the
> [list of 
> goals](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html):
> 
>> **String re-evaluation**: String is one of the most important fundamental
>> types in the language.  The standard library leads have numerous ideas of how
>> to improve the programming model for it, without jeopardizing the goals of
>> providing a unicode-correct-by-default model.  Our goal is to be better at
>> string processing than Perl!
> 
> For Swift 4 and beyond we want to improve three dimensions of text processing:
> 
>  1. Ergonomics
>  2. Correctness
>  3. Performance
> 
> This document is meant to both provide a sense of the long-term vision 
> (including undecided issues and possible approaches), and to define the scope 
> of
> work that could be done in the Swift 4 timeframe.
> 
> ## General Principles
> 
> ### Ergonomics
> 
> It's worth noting that ergonomics and correctness are mutually-reinforcing.  
> An
> API that is easy to use—but incorrectly—cannot be considered an ergonomic
> success.  Conversely, an API that's simply hard to use is also hard to use
> correctly.  Acheiving optimal performance without compromising ergonomics or
> correctness is a greater challenge.
> 
> Consistency with the Swift language and idioms is also important for
> ergonomics. There are several places both in the standard library and in the
> foundation additions to `String` where patterns and practices found elsewhere
> could be applied to improve usability and familiarity.
> 
> ### API Surface Area
> 
> Primary data types such as `String` should have APIs that are easily 
> understood
> given a signature and a one-line summary.  Today, `String` fails that test.  
> As
> you can see, the Standard Library and Foundation both contribute 
> significantly to
> its overall complexity.
> 
> **Method Arity** | **Standard Library** | **Foundation**
> ---|:---:|:---:
> 0: `ƒ()` | 5 | 7
> 1: `ƒ(:)` | 19 | 48
> 2: `ƒ(::)` | 13 | 19
> 3: `ƒ(:::)` | 5 | 11
> 4: `ƒ()` | 1 | 7
> 5: `ƒ(:)` | - | 2
> 6: `ƒ(::)` | - | 1
> 
> **API Kind** | **Standard Library** | **Foundation**
> ---|:---:|:---:
> `init` | 41 | 18
> `func` | 42 | 55
> `subscript` | 9 | 0
> `var` | 26 | 14
> 
> **Total: 205 APIs**
> 
> By contrast, `Int` has 80 APIs, none with more than two parameters.[0] String 
> processing is complex enough; users shouldn't have
> to press through physical API sprawl just to get started.
> 
> Many of the choices detailed below 

Re: [swift-evolution] Strings in Swift 4

[Jean-Daniel via swift-evolution]

> Le 20 janv. 2017 à 05:07, Saagar Jha via swift-evolution 
>  a écrit :
> 
> Looks pretty good in general from my quick glance–at least, it’s much better 
> than the current situation. I do have a couple of comments and questions, 
> which I’ve inlined below.
> 
> Saagar Jha
> 
>> …
> 
> Any reason why Locale is defaulted to nil, instead of currentLocale? It seems 
> more useful to me.



Don’t know the rational here, but it may prevent a lots of bugs.
Having a call that behave differently depending the system locale is a pain. I 
can’t recall how many time I had ti fix tests cases because they where 
implicitly relying on the default locale.
It also caused many issue with scanning and formatting non localized values as 
you have to explicitly specify a neutral local which is usually not properly 
done by the developers.

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

Re: [swift-evolution] Strings in Swift 4

[Charlie Monroe via swift-evolution]

> On Jan 20, 2017, at 12:55 PM, Maxim Veksler via swift-evolution 
>  wrote:
> 
> Please see discussion inline.
> 
> On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira 
> > 
> wrote:
> 
> > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution 
> > > wrote:
> >
> > One ask - make string interpolation great again?
> >
> > Taking from examples supplied at 
> > https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation
> >  
> > 
> >
> > "Column 1: \(n.format(radix:16, width:8)) *** \(message)"
> >
> > Why not use:
> >
> > "Column 1: ${n.format(radix:16, width:8)} *** $message"
> >
> > Which for my preference makes the syntax feel more readable, avoids the 
> > "double ))" in terms of string interpolation termination and function 
> > termination points. And if that's not enough brings the "feel" of the 
> > language to be scriptable in nature common in bash, sh, zsh and co.. 
> > scripting interpreters and has been adopted as part of ES6 interpolation 
> > syntax[1].
> >
> 
> This idea came up once before on Swift Evo. The arguments against are:
> 
> 1. Swift already has an “escape” character for inserting non literal stuff 
> into strings - the “\” character. Either you have two - increasing complexity 
> for both the developer and the Swift compiler’s tokeniser - or you have to 
> change everything that uses “\” to use $ e.g. $t $n instead of \t \n.
> 
> 
> I would claim that this serves as an reinforcement of making the 
> distinctions. "\t" is not the same behavior as "\(someVariable)" both 
> conceptually - I think there is a clear distinction between inserting a 
> "constant symbol" to inserting "the string content of a variable" and 
> semantically - While you would use \t to insert a tab you are mandated by the 
> semantics to use \( .. ) to insert the contents of a variable.

Hi Maxim,

there was quite a discussion on this matter a few months ago - I can't find the 
thread right now, but the consensus of majority here seemed to be that the 
current status is desirable by most and that it contains some unified 
philosophy over anything that will "not print as typed". I believe that this is 
something that has been discussed here several times - keep in mind Swift 4 is 
supposed to be as much backward compatible as possible with breaking changes 
requiring severe justification - there is unlikely to be one for this other 
than "I like it better this way".

>  
> 2. The dollar sign is a disastrous symbol to use for an special character, 
> especially in the USA where it is commonly used to signify the local 
> currency. Yes, I know it is used for interpolation in Perl, Shell and 
> Javascript and others,  but “this other language I like does X, therefore 
> Swift should do X” is not a good argument.
> 
> 
> Please name concrete examples? I would believe that the case for 
> $variableName to be rare enough to justify expecting the developer to make an 
> escape claim with \$variableName, likewise for ${variableName}, if expected 
> output is plain text I wouldn't imagine this "\$\{variableName\}" to be a far 
> reaching expectation.
> 
> The use of $ symbol is more reaching[1], and is being adopted constantly as 
> the selected patten for even recent developments as Facebook's GraphQL query 
> syntax[2] which to the best of my knowledge was invented in US. 
> 
> 3. There is already quite a lot of code that uses \( … ) for interpolation, 
> this would be a massive breaking change.
> 
> 
> True, but going forward that would enable a "better readable" code for larger 
> number of users. Additionally I would suggest that automatic conversion using 
> Swift Migration Assistant should be possible.
> 
> 
> ___
> 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

Re: [swift-evolution] Strings in Swift 4

[Maxim Veksler via swift-evolution]

Please see discussion inline.

On Fri, Jan 20, 2017 at 1:09 PM Jeremy Pereira <
jeremy.j.pere...@googlemail.com> wrote:

>
> > On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > One ask - make string interpolation great again?
> >
> > Taking from examples supplied at
> https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation
> >
> > "Column 1: \(n.format(radix:16, width:8)) *** \(message)"
> >
> > Why not use:
> >
> > "Column 1: ${n.format(radix:16, width:8)} *** $message"
> >
> > Which for my preference makes the syntax feel more readable, avoids the
> "double ))" in terms of string interpolation termination and function
> termination points. And if that's not enough brings the "feel" of the
> language to be scriptable in nature common in bash, sh, zsh and co..
> scripting interpreters and has been adopted as part of ES6 interpolation
> syntax[1].
> >
>
> This idea came up once before on Swift Evo. The arguments against are:
>
> 1. Swift already has an “escape” character for inserting non literal stuff
> into strings - the “\” character. Either you have two - increasing
> complexity for both the developer and the Swift compiler’s tokeniser - or
> you have to change everything that uses “\” to use $ e.g. $t $n instead of
> \t \n.
>
>
I would claim that this serves as an reinforcement of making the
distinctions. "\t" is not the same behavior as "\(someVariable)" both
conceptually - I think there is a clear distinction between inserting a
"constant symbol" to inserting "the string content of a variable" and
semantically - While you would use \t to insert a tab you are mandated by
the semantics to use \( .. ) to insert the contents of a variable.


> 2. The dollar sign is a disastrous symbol to use for an special character,
> especially in the USA where it is commonly used to signify the local
> currency. Yes, I know it is used for interpolation in Perl, Shell and
> Javascript and others,  but “this other language I like does X, therefore
> Swift should do X” is not a good argument.
>
>
Please name concrete examples? I would believe that the case for
$variableName to be rare enough to justify expecting the developer to make
an escape claim with \$variableName, likewise for ${variableName}, if
expected output is plain text I wouldn't imagine this "\$\{variableName\}"
to be a far reaching expectation.

The use of $ symbol is more reaching[1], and is being adopted constantly as
the selected patten for even recent developments as Facebook's GraphQL
query syntax[2] which to the best of my knowledge was invented in US.

3. There is already quite a lot of code that uses \( … ) for interpolation,
> this would be a massive breaking change.
>
>
True, but going forward that would enable a "better readable" code for
larger number of users. Additionally I would suggest that automatic
conversion using Swift Migration Assistant should be possible.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[Jeremy Pereira via swift-evolution]

> On 20 Jan 2017, at 10:30, Maxim Veksler via swift-evolution 
>  wrote:
> 
> One ask - make string interpolation great again?
> 
> Taking from examples supplied at 
> https://github.com/apple/swift/blob/master/docs/StringManifesto.md#string-interpolation
> 
> "Column 1: \(n.format(radix:16, width:8)) *** \(message)"
> 
> Why not use:
> 
> "Column 1: ${n.format(radix:16, width:8)} *** $message"
> 
> Which for my preference makes the syntax feel more readable, avoids the 
> "double ))" in terms of string interpolation termination and function 
> termination points. And if that's not enough brings the "feel" of the 
> language to be scriptable in nature common in bash, sh, zsh and co.. 
> scripting interpreters and has been adopted as part of ES6 interpolation 
> syntax[1]. 
> 

This idea came up once before on Swift Evo. The arguments against are:

1. Swift already has an “escape” character for inserting non literal stuff into 
strings - the “\” character. Either you have two - increasing complexity for 
both the developer and the Swift compiler’s tokeniser - or you have to change 
everything that uses “\” to use $ e.g. $t $n instead of \t \n.  

2. The dollar sign is a disastrous symbol to use for an special character, 
especially in the USA where it is commonly used to signify the local currency. 
Yes, I know it is used for interpolation in Perl, Shell and Javascript and 
others,  but “this other language I like does X, therefore Swift should do X” 
is not a good argument.

3. There is already quite a lot of code that uses \( … ) for interpolation, 
this would be a massive breaking change.

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

Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

[Gwendal Roué via swift-evolution]

https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md

>   • What is your evaluation of the proposal?

+1 Enthousiastic!

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes, because library developers are required to declare generic methods, even 
when a subscript would look and feel more natural at the call site.

>   • Does this proposal fit well with the feel and direction of Swift?

Yes, because consistency simplifies the language: there was no good reason for 
subscripts not te be generic, except implementation details of the Swift 
compiler.

I'll use the same arguments to support throwing subscripts.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

No, I don't.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I've been waiting this for years, for the SQLite library 
http://github.com/groue/GRDB.swift

Cheers,
Gwendal

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

Re: [swift-evolution] [Review] SE-0148 Generic Subscripts

[Radosław Pietruszewski via swift-evolution]

I’m +1 for the proposal.

Context, in case it’s useful for anyone: My particular use case for generic 
subscripts is with my SwiftyUserDefaults library 
(https://github.com/radex/SwiftyUserDefaults 
), which allows users to access 
user defaults with a syntax like: `Defaults[.foo]` and `Defaults[.foo] = 20`, 
in a type-safe way. `.foo` refers to a `DefaultsKey` object, where T is the 
type stored in the user defaults. Right now, I’m forced to define multiple 
subscripts to support the standard types of user defaults, but it takes a lot 
of boilerplate code. Generic subscripts would abstract this away (with a help 
of a protocol to mark which types are supported). There’s also no good way to 
allow nested types like `[String]` or `[String: [Int]]`.

Best,
— Radek

> On 19 Jan 2017, at 22:39, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0148 “Generic Subscripts" begins now and runs through 
> January 24, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> 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

Re: [swift-evolution] Closures from methods with default args

[Charlie Monroe via swift-evolution]

> On Jan 20, 2017, at 6:07 AM, David Sweeris  wrote:
> 
> 
> On Jan 9, 2017, at 02:13, Charlie Monroe via swift-evolution 
> > wrote:
> 
>> I came across something that I'm not sure it's a bug or by design and if 
>> it's by design, whether this should be discussed here.
>> 
>> Example:
>> 
>> class Foo {
>> init(number: Int) { /* ... */ }
>> }
>> 
>> let closure = Foo.init(number:) // (Int) -> Foo
>> [1, 2, 3].map(closure) // [Foo, Foo, Foo]
>> 
>> This works great until the initializer gets a default argument:
>> 
>> class Foo {
>> init(number: Int, string: String = "") { /* ... */ }
>> }
>> 
>> // Error: Foo has no member init(number:)
>> let closure = Foo.init(number:) 
>> 
>> I was wondering if we could get closures to methods without the default 
>> arguments. Currently, this needs to be worked around by e.g. creating a 
>> second closure that invokes the method without the default arguments:
>> 
>> let closure: (Int) -> Foo = { Foo(number: $0) }
>> 
>> But to me it seems like something that should work "out of the box".
>> 
>> Thoughts?
> 
> IIRC, this issue was raised a while ago, and as best as I recall the gist of 
> the answer was that default arguments are implemented at the call site, and 
> because of that you can't pass a function with default arguments to something 
> expecting a function with fewer arguments even though the two calls look 
> identical in the source code.
> 
> It causes other issues, too. For instance, if we have
> protocol Initable { init() }
> And
> struct Foo { init(_ x: Int = 0) {} }
> We're left in an odd situation where `Foo`  can't meaningfully conform to 
> `Initable` because while "init(_: Int = 0)" is not the same as "init()", if 
> you add a "init()" to `Foo`
> you'll get an ambiguous somethingerather error because there's no mechanism 
> for the compiler to know whether you want the actual "0 argument" function or 
> the "1 argument with 1 default value" function.
> 

Sure, but in the case of the closure, it shouldn't be a major issue for the 
compiler to automatically generate a "proxy" closure that would call the 
implementation with supplied parameters + rest as default - just like with the 
current workaround.

If no one thinks that this is something that needs to go through the evolution 
process (in case there is e.g. a good reason why this shouldn't work), I'll 
just file this as a bug/enhancement request at bugs.swift.org 
. 

> Aside from re-architecting the default argument system (which I'm not even 
> sure is possible, let alone a good idea), I think I see couple ways forward 
> for the protocol conformance issue. Both have downsides, though.
> 
> 1) Require any potentially conflicting protocol functions to be in an 
> extension so the compiler knows what's going on, have "Foo()" call the one 
> defined in the type, and use "(Foo as Initable)()" for the protocol version 
> defined in an extension. This could get real confusing real fast if people 
> don't realize there's two functions with, as far as they can tell, the same 
> signature.
> 
> 2) Add default argument support to protocols. The syntax that makes sense to 
> me would be something like
> protocol Bar {
> func baz(_: Int = _)
> }
> On the downside, I suspect this would necessarily add a phantom "Self or 
> associated type requirement" so that the compiler could have a way to get at 
> each implementation's default value. It's not ideal... You'd get an error 
> kinda out of the blue if you tried to use the function non-generically, but 
> at least you couldn't have a function change out from under you.
> 
> - Dave Sweeris 

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

Re: [swift-evolution] Method dispatching issue with subclasses implementing Equatable protocol.

[Francisco Javier Fernández Toro via swift-evolution]

On Wed, Jan 18, 2017 at 6:58 PM, Tony Allevato 
wrote:

> Ok, this actually does feel a bit strange. The behavior you're seeing
> seems to be a consequence of [SE-0091](https://github.com/
> apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-
> protocols.md), but it looks like you're seeing different behavior than
> what I described in the "Class types and inheritance" section of that
> proposal.
>
> If Sub has `==(Sub, Sub)` implemented as a *static* function, I just tried
> it and it's *ignored* (`==(Super, Super)` gets called instead), even when
> the two actual arguments are known to be statically of type Sub. I think
> this is because of the way that proposal was implemented: when it sees that
> `Sub` extends `Super`, which conforms to `Equatable`, it appears that it's
> only looking for static overloads of `==` that are satisfied at the *point
> of conformance*, which would be `==(Super, Super)` (because `Super`
> conforms to `Equatable where Self == Super`). The wording of the proposal
> makes this case: "Then, we say that we do not consider an operator function
> if it implements a protocol requirement, because the requirement is a
> generalization of all of the operator functions that satisfy that
> requirement."
>
> Contrarily, if you provide `==(Sub, Sub)` as a global function instead of
> a static one, it *does* get called. I think in this case, the type checker
> gets the whole set of candidate operators (which, unlike above, includes
> the global `==(Sub, Sub)`), and it gets used because it's a more specific
> match?
>
>
FWIW, I've just changed both `==` functions to make them global, the the
outcome is still the same, its using `==(Super,Super)` to resolve
`!=(Sub,Sub)


> Can someone from the core team chime in and say whether this is
> intentional behavior? It feels wrong that simply changing the location
> where the operator is defined would change the behavior like this.
>
> FWIW, to avoid these sharp edges, there's no need to implement `==` for
> subtypes; since you have to use an overridable `equals` method anyway, just
> have the base type implement `==` to delegate to it, and then have subtypes
> override `equals` alone.
>
>
> On Wed, Jan 18, 2017 at 9:36 AM Francisco Javier Fernández Toro <
> f...@gokarumi.com> wrote:
>
>> Yeah guys, you are right, my code is busted, I was trying to point
>> something different out:
>>
>> The next code is showing the possible issue. In theory to make a class
>> Equatable, you just have to mark it with the Equatable protocol and
>> implement `==` as a static function or as a global one.
>>
>> If you don't override the equal method and you just invoke your super
>> class equality method you'll get something like this:
>>
>> ```
>> class Superclass : Equatable {
>> let foo: Int
>>
>> init(foo: Int) { self.foo = foo }
>>
>> func equal(to: Superclass) -> Bool {
>> return foo == to.foo
>> }
>>
>> static func == (lhs: Superclass, rhs: Superclass) -> Bool {
>> return lhs.equal(to: rhs)
>> }
>> }
>>
>> class Subclass: Superclass {
>> let bar: Int
>> init(foo: Int, bar: Int) {
>> self.bar = bar
>> super.init(foo: foo)
>> }
>>
>> func equal(to: Subclass) -> Bool {
>> return bar == to.bar && super.equal(to: to)
>> }
>>
>> static func == (lhs: Subclass, rhs: Subclass) -> Bool {
>> return lhs.equal(to: rhs)
>> }
>> }
>>
>> class SubclassWithDifferentOperator: Subclass {
>> static func != (lhs: SubclassWithDifferentOperator, rhs:
>> SubclassWithDifferentOperator) -> Bool {
>> return !(lhs.equal(to: rhs))
>> }
>> }
>>
>> let a = Subclass(foo: 1, bar: 1)
>> let b = Subclass(foo: 1, bar: 2)
>>
>> (a == b) != (a != b) // Prints: false, not expected
>>
>> let x = SubclassWithDifferentOperator(foo: 1, bar: 1)
>> let y = SubclassWithDifferentOperator(foo: 1, bar: 2)
>>
>> (x == y) != (x != y) // Prints: true, expected
>> ```
>>
>> So, after adding a couple of `print` statement in those equal method what
>> I can see is that for Subclass, when you are need to call `!=` what Swift
>> is doing is using `func ==(Superclass, Superclass)` and apply `!` as Tony
>> has pointed out.
>>
>> What I cannot understand is why is not using `func == (Subclass,
>> Subclass)`
>>
>> I hope it makes more sense now.
>>
>> ---
>> Fran Fernandez
>>
>> On Wed, Jan 18, 2017 at 6:13 PM, Tony Allevato 
>> wrote:
>>
>> This seems to work for me:
>>
>> ```
>> class Super: Equatable {
>> let x: Int
>> init(x: Int) {
>> self.x = x
>> }
>> func equals(_ rhs: Super) -> Bool {
>> return x == rhs.x
>> }
>> static func ==(lhs: Super, rhs: Super) -> Bool {
>> return lhs.equals(rhs)
>> }
>> }
>>
>> class Sub: Super {
>> let y: Int
>> init(x: Int, y: Int) {
>> self.y = y
>> super.init(x: x)
>> }
>> override func equals(_ rhs: Super) -> Bool {

Re: [swift-evolution] Assigning to 'self' in protocol extensions

[rintaro ishizaki via swift-evolution]

> In the specific case of initializers, my opinion here is the opposite in
>> fact — I think assigning to ‘self’ should be permitted in all convenience
>> initializers, even initializers defined directly classes, without the
>> protocol extension trick. Also, we should lower this more efficiently than
>> we do today, without creating a self ‘carcass’ that is allocated and
>> immediately freed, to be replaced by the ‘real’ self.
>>
>>
> I totally agree. And I think that is the least impact way on the language
> specification.
>
>
Oops, It seems I have to take back my words.
With my "factory initializer" example:

  let dog = Dog(type: "cat")
  type(of: dog) == Cat.self

results "true".
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Assigning to 'self' in protocol extensions

[rintaro ishizaki via swift-evolution]

2017-01-20 16:11 GMT+09:00 Slava Pestov :

>
> Is your proposal to ban calls to such mutating methods on a type that is
> known to be a reference type at compile time altogether? This will create
> an inconsistency between code that operates on concrete types and code that
> operates on generic parameters (in the latter case the compiler of course
> has no way to statically guarantee that the value is not a reference type).
>
>
The last time this quirk came up in internal discussions, the thought some
> of us had was that it might be worthwhile to prohibit classes from
> conforming to protocols with mutating requirements altogether. If you think
> about it, this makes some amount of sense — it seems like it would be quite
> hard to write code that can operate on both mutable values and mutable
> references generically, since the latter do not have value semantics:
>
> var x = y
> x.mutatingProtocolRequirement()
> // did y change too?
>
> However the discussion sort of fizzled out.
>
> Perhaps we can resurrect it as a proposal, but the bar is pretty high for
> removing features at this point, since there’s no actual type soundness
> issue, just possible confusion.
>
>
Well, I'm not proposing anything for now.
I'm totally OK to leave it as is if the community think so.
If so, I just want to confirm that the language feature truly support this.
At least, I don't want to propose something that breaks source
compatibility.

> Default implementation for initializers
>
> Similar to methods, initializers also have this issue:
>
> In the specific case of initializers, my opinion here is the opposite in
> fact — I think assigning to ‘self’ should be permitted in all convenience
> initializers, even initializers defined directly classes, without the
> protocol extension trick. Also, we should lower this more efficiently than
> we do today, without creating a self ‘carcass’ that is allocated and
> immediately freed, to be replaced by the ‘real’ self.
>
>
I totally agree. And I think that is the least impact way on the language
specification.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution