Re: [swift-evolution] [Pitch] Add Null struct to Foundation

[Michael Peternell via swift-evolution]

> Am 24.06.2016 um 07:59 schrieb J. Charles M. N. via swift-evolution 
> :
> 
> Doesn't Optional.None allready a placeholder for null values in swift?

Not really. What is the type of Optional.none? `let empty = Optional.none` does 
not compile, it says "Generic parameter 'Wrapped' could not be inferred". 
NSNull() is a unique concrete value, and it's compatible with Objective C, 
NSObject and AnyObject. We could of course use `Optional.none`, but 
someone else may use `Optional.none` instead. The extra type 
information is just misleading in this case.

> 
> I read some where that nil was the new way to represent null pointer in 
> swift. 

It is, usually. But does it work in this case?

-Michael

> 
> --
> J. Charles 
> 
>> Le 24 juin 2016 à 00:59, Michael Peternell via swift-evolution 
>>  a écrit :
>> 
>> I think NSNull() should be used, not a struct. I don't think that a struct 
>> would be more performant. Or maybe the performance doesn't matter at all in 
>> any real-world usage scenario. But you may write a benchmark of a realistic 
>> (!) use-case (!) if you think otherwise... would be interesting to see the 
>> results.
>> 
>> Keeping with NSNull() also simplifies objc-interoperability.
>> 
>> -Michael
>> 
>>> Am 23.06.2016 um 06:14 schrieb Alsey Miller via swift-evolution 
>>> :
>>> 
>>> Add a struct Null to the Swift 3.0 Foundation value types. As a struct, 
>>> Null is more performant (no ARC or memory allocation) than NSNull, and will 
>>> be needed for Swift JSON decoders and libraries that want to use struct 
>>> value types, and be free from classes for their model layer.
>>> 
>>> 
>>>   Coleman,
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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
> 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] [Review] SE-0104: Protocol-oriented integers

[Nicola Salmoria via swift-evolution]

On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev  wrote:

> Hi Nicola,
>
> > For these reasons, I think it would make sense to explicitly request that
> > the remainder operation never traps, and remove the overflow variants.
> It will still trap when you divide by 0. But in that case falling back to
> the same generic overflow logic is not the best idea.
> I agree that remainder is special, let me see what I can do about it.
>
>
LOL, yes of course, I forgot about the obvious trapping case.

However, division by 0 isn't an overflow: it's an undefined operation. I
find it somewhat surprising that dividedWithOverflow/remainderWithOverflow
allow attempting this operation.

To me, the intuitive semantics of the WithOverflow methods are "perform the
operation, and if the result doesn't fit in the given type, return a
truncated result and an overflow flag". This is not what happens when
dividing by 0, because the result simply doesn't exist.

I think I would prefer if rhs != 0 was documented as an explicit
precondition of the division and remainder operations, and
dividedWithOverflow/remainderWithOverflow trapped because of precondition
failure.

If it is desirable that the WithOverflow methods never trap, then I think
it would be better to add a `divisionByZero` case to the ArithmeticOverflow
enum and return that instead of the generic `overflow`.

Thanks,
Nicola



> Thanks,
> Max
>
>
> > On Jun 23, 2016, at 2:38 PM, Nicola Salmoria via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Max Moiseev via swift-evolution  writes:
> >
> >>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under
> > what situations would
> >> you have an overflow? I could only come up with something like
> > Int.min.dividedWithOverflow(-1).
> >> If you look at the prototype here:
> >>
> > https://github.com/apple/swift/blob/master/test/Prototypes
> > /Integers.swift.gyb#L789
> >> there is
> >> exactly the check that you’ve mentioned, but for all signed integers.
> > Besides, it is very convenient to
> >> have all the arithmetic operations be implemented the same way, even if
> > there were no real overflows for division.
> >
> > I agree with this for the four basic operations, but not for the
> remainder
> > operation.
> >
> > By definition, the remainder is always strictly smaller (in absolute
> value)
> > than the divisor, so even if the division itself overflows, the remainder
> > must be representable, so technically it never overflow.
> >
> > In the only actual case where the division overflow, that is Int.min /
> -1,
> > the remainder is simply 0.
> >
> > For these reasons, I think it would make sense to explicitly request that
> > the remainder operation never traps, and remove the overflow variants.
> >
> > Nicola
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>

On Fri, Jun 24, 2016 at 12:12 AM, Max Moiseev  wrote:

> Hi Nicola,
>
> > For these reasons, I think it would make sense to explicitly request that
> > the remainder operation never traps, and remove the overflow variants.
> It will still trap when you divide by 0. But in that case falling back to
> the same generic overflow logic is not the best idea.
> I agree that remainder is special, let me see what I can do about it.
>
> Thanks,
> Max
>
>
> > On Jun 23, 2016, at 2:38 PM, Nicola Salmoria via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Max Moiseev via swift-evolution  writes:
> >
> >>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under
> > what situations would
> >> you have an overflow? I could only come up with something like
> > Int.min.dividedWithOverflow(-1).
> >> If you look at the prototype here:
> >>
> > https://github.com/apple/swift/blob/master/test/Prototypes
> > /Integers.swift.gyb#L789
> >> there is
> >> exactly the check that you’ve mentioned, but for all signed integers.
> > Besides, it is very convenient to
> >> have all the arithmetic operations be implemented the same way, even if
> > there were no real overflows for division.
> >
> > I agree with this for the four basic operations, but not for the
> remainder
> > operation.
> >
> > By definition, the remainder is always strictly smaller (in absolute
> value)
> > than the divisor, so even if the division itself overflows, the remainder
> > must be representable, so technically it never overflow.
> >
> > In the only actual case where the division overflow, that is Int.min /
> -1,
> > the remainder is simply 0.
> >
> > For these reasons, I think it would make sense to explicitly request that
> > the remainder operation never traps, and remove the overflow variants.
> >
> > Nicola
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
sw

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

[Xiaodi Wu via swift-evolution]

On Fri, Jun 24, 2016 at 12:59 AM, William Shipley via swift-evolution <
swift-evolution@swift.org> wrote:

> Here are some of my real-world examples:
>
> for modelUUIDAndInterfaceElement in modelUUIDsToInterfaceElements
> where !usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
>

Not a practitioner of 80-character line limits, I take it?


> …
>
> }
>
> for anchor in wall.anchors where boundsRect.contains(anchor.origin)
> {
>
> …
>
> }
>
> for otherWall: Wall in self where otherWall != wall &&
> !removedWalls.contains(otherWall) {
>
> …
>
> }
>
> for wall in self as Set {
> for otherWall in self as Set where otherWall != wall {
>
> …
>
> }
> }
>
> for wall in self as Set where !checkedWalls.contains(wall) {
>
> …
>
> }
>
> (x2 on that one)
>
> for otherPieceOfFurnitureNode in
> localFurnitureModelUUIDsToInterfaceElements!.values where
> otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
>
> …
>
> }
>
> for lineSegmentObject in wallRelatedLineSegments where
> remainingLineSegments.contains(lineSegmentObject) {
>
> …
>
> }
>
> for colinearLineSegmentObject in remainingLineSegments where
> colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle:
> lineSegmentObject.angle) {
>
> …
>
> }
>
>
> I think this is basically as many as are found on all of github?
>
> -W
>
> ___
> 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] SE-0105: Removing Where Clauses from For-In Loops

[William Shipley via swift-evolution]

Here are some of my real-world examples:

for modelUUIDAndInterfaceElement in modelUUIDsToInterfaceElements where 
!usedInterfaceElements.contains(modelUUIDAndInterfaceElement.1) {
…
}

for anchor in wall.anchors where boundsRect.contains(anchor.origin) {
…
}

for otherWall: Wall in self where otherWall != wall && 
!removedWalls.contains(otherWall) {
…
}

for wall in self as Set {
for otherWall in self as Set where otherWall != wall {
…
}
}

for wall in self as Set where !checkedWalls.contains(wall) {
…
} 

(x2 on that one)

for otherPieceOfFurnitureNode in 
localFurnitureModelUUIDsToInterfaceElements!.values where 
otherPieceOfFurnitureNode !== pieceOfFurnitureNode {
…
}

for lineSegmentObject in wallRelatedLineSegments where 
remainingLineSegments.contains(lineSegmentObject) {
…
}

for colinearLineSegmentObject in remainingLineSegments where 
colinearLineSegmentObject.angle.isEssentially(infiniteLineAngle: 
lineSegmentObject.angle) {
…
}


I think this is basically as many as are found on all of github?

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

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

[J. Charles M. N. via swift-evolution]

Doesn't Optional.None allready a placeholder for null values in swift?

I read some where that nil was the new way to represent null pointer in swift. 

--
J. Charles 

> Le 24 juin 2016 à 00:59, Michael Peternell via swift-evolution 
>  a écrit :
> 
> I think NSNull() should be used, not a struct. I don't think that a struct 
> would be more performant. Or maybe the performance doesn't matter at all in 
> any real-world usage scenario. But you may write a benchmark of a realistic 
> (!) use-case (!) if you think otherwise... would be interesting to see the 
> results.
> 
> Keeping with NSNull() also simplifies objc-interoperability.
> 
> -Michael
> 
>> Am 23.06.2016 um 06:14 schrieb Alsey Miller via swift-evolution 
>> :
>> 
>> Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null 
>> is more performant (no ARC or memory allocation) than NSNull, and will be 
>> needed for Swift JSON decoders and libraries that want to use struct value 
>> types, and be free from classes for their model layer.
>> 
>> 
>>Coleman,
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Fwd: [Draft] Rationalizing Sequence end-operation names

[Xiaodi Wu via swift-evolution]

Yikes, not only is the email too big for some mail clients, it's too big
for the mailing list. Resending with proposal snipped.

On Thu, Jun 23, 2016 at 1:24 PM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> Most of your proposal look great to me! Comments inline:
>
> On 23 Jun 2016, at 09:19, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> As previously threatened mentioned, I've written a draft proposal to fix
> a number of naming issues with APIs operating on the beginning and end of
> Sequences and Collections:
>
> • Inconsistent use of `prefix`/`suffix` vs. `first`/`last`
> • Confusing naming of `drop` methods
> • Ambiguous naming of `index(of:/where:)` and `drop(while:)`
> • `prefix(upTo:)`, `prefix(through:)`, and `suffix(from:)` shouldn't be
> part of this family at all
>
> To fix this, I propose:
>
> • Renaming all methods which operate on more than one element at the
> beginning/end to use "prefix" or "suffix", not "first" or "last"
>
> Looking at the first column in your table, I think the current API focuses
correctly on the number of elements returned (and consequently, the return
type) rather than the number of elements interrogated. "First" and "last"
on their own suggest very strongly that you get back either zero elements
or one element (thus, an optional would be the appropriate return type),
whereas "prefix" and "suffix" suggest 0 to all elements might be returned
(thus, an array or collection would be the appropriate return type).
Currently, the API adheres to that expectation as far as your "get" column
is concerned, and IMO the most consistent approach would be to whip the
remaining columns in line.

To me, `first(where:)` is unambiguous and doubly distinguished from
`prefix(while:)`--even when the argument label is dropped in trailing
closure syntax, it is clear that `first` gives you at most one, and by
contradistinction `prefix` gives you at most all. I'm not sure that
"earliest" is an improvement, since you're introducing another word and
breaking the parallels here. So on reflection, I'm satisfied that first,
prefix, last, suffix all have their place in the API. Of course, I think
you could make a case for an across-the-board renaming of "first" to
"earliest" and "last" to "latest"--in fact, there could be an argument that
given 0-based indices the word "first" is an unfortunate choice in any case.

> • Renaming `index(of:/where:)` to `earliestIndex(…)` and `first(where:)`
> to `earliest(where:)`
> • Renaming the `drop` methods to use `removing`
>
>
> +! Everything above, I strongly agree with!
>
> • Redesigning `prefix(upTo:)`, `prefix(through:)` and `suffix(from:)` as
> subscripts with "partial" ranges, like `people[.. `people[nil..
>
> I’m not a fan of the subscript solutions. They both introduce new types
> which seems very heavyweight for such a small use case. I’d vote for
> keeping the current functions.
>

Ditto, not a fan of a subscript solution here. It is true that
`suffix(from:)` seems weird at first, but it is literally nonsensical to
interpret the single argument any other way, partly because of the
mandatory argument label but mostly because a "suffix" that doesn't go to
the end isn't a suffix.

(Personally, though, I always thought `upTo` was an ineffective attempt to
clarify the distinction with `through`, since either you were familiar with
`stride(from:to:by:)` and `stride(from:through:by:)` or you weren't, and if
you weren't `upTo` is just as opaque as `to`.)


>
> Since that last point requires significant redesign, including the
> introduction of new types, I have also included an alternative design which
> uses `people[to: idx]` instead.
>
> This proposal does not seek to add new functionality; it merely renames or
> (in the case of the "aggressive" subscript option) redesigns existing
> functionality. I do, however, discuss (without making many judgements about
> their wisdom) how these changes might affect the naming of functionality we
> might add in future versions of Swift.
>
> I would mainly like feedback on the two most open questions left in this
> proposal:
>
> • The choice of `removing` to replace `drop`
>
>
> Yep, heavily agree with you on `removing`.
>

I think `removing` is an improvement. That said, your proposal raises a
good point that the return type goes against expectations for an `ed/ing`
counterpart. If you're looking for an alternative name, there's a pretty
good one at the top of your very nice table: `excluding`. It's a commonly
used English word, conveys exactly what's going on, and isn't scary and
verb-sounding like `drop`.


>
> • The decision about whether to use `people[.. or `people[to: idx]`.
>
>
> None of the above, as stated previously :)
>

Yeah, not so much of a fan here either :/


>
> But I'd also like comments on the rest of the proposal, and on whether I
> should split the prefix(upTo:/through:)/suffix(from:) changes into a
> separate proposal from the rest.
>
> 

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

[Xiaodi Wu via swift-evolution]

On Fri, Jun 24, 2016 at 12:45 AM, Guillaume Lessard via swift-evolution <
swift-evolution@swift.org> wrote:

> I like this draft. Quickly:
>
> - “removing” sounds more destructive than “skipping”, so I’d lean towards
> using “skipping”. I would be happy with either, though.
> - there are two different labels for predicates (where and while). “where”
> is probably the better label. (some previous discussion had seemingly
> arrived to that conclusion:
> http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/)
>

I think this is going to the distinction that "where" is now supposed to
correspond to "continue" inside a loop if the predicate isn't satisfied,
whereas "while" is supposed to correspond to "break" inside a loop if the
predicate isn't satisfied. Then again, I've argued elsewhere on this list
that the distinction isn't nearly as obvious as some seem to think it is,
and I think we have another demonstration of that here :)


>
> I like the idea of making the index-based slicing operations look more
> like slicing operations. I have on occasion wanted the operators you
> describe in the “aggressive” option; I approve.
>
> Cheers,
> Guillaume Lessard
>
> ___
> 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] [Draft] Rationalizing Sequence end-operation names

[Guillaume Lessard via swift-evolution]

I like this draft. Quickly:

- “removing” sounds more destructive than “skipping”, so I’d lean towards using 
“skipping”. I would be happy with either, though.
- there are two different labels for predicates (where and while). “where” is 
probably the better label. (some previous discussion had seemingly arrived to 
that conclusion: 
http://article.gmane.org/gmane.comp.lang.swift.evolution/16334/)

I like the idea of making the index-based slicing operations look more like 
slicing operations. I have on occasion wanted the operators you describe in the 
“aggressive” option; I approve.

Cheers,
Guillaume Lessard

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol` syntax with `P1 & P2`

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)
> On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>  ]
> 
> I’ve gone on record before as against this syntax, although when I set out 
> earlier today to record my usual rebuttal I found that it really was mostly a 
> matter of taste. Yes, this looks weird to me:
> 
> let callback: (Data) -> NSCoding & NSCopying
> 
> but I’m sure the infix ‘->’ for functions looked weird to everyone the first 
> time they saw it as well, and it really is pretty clear in argument position.
> 
> However, I did remember one issue, which was brought up on the previous 
> mega-thread: if we do want to generalize protocol values, we’re going to want 
> something that’s essentially “a type with a ‘where’ clauses in it”. I really 
> don’t want to force people to use a typealias to spell such a type, but at 
> the same time I want that where clause to be clearly attached to the type. 
> (As brought up before the return position of a function is currently 
> ambiguous with SE-0081.)
> 
> Despite the lightweightedness and the well-prepared proposal by Adrian and 
> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
> against the proposed syntax.

This is another way to generalize P&Q compositions that opens another way to 
specify WHERE

https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051

> 
> Jordan
> 
> ___
> 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] [Draft] UnsafeRawPointer API

[L. Mihalkovic via swift-evolution]

Very cool...

Couple thoughts

UnsafeMutableRawPointer:
func store(, WITH: T)
does not flow very well
Fill:with: seems nicer or write(, from:T) which means changing 'load' into 
'read'
func read(_ : T.Type) -> T
func write(_: T.T.Type, from: T) (write even match the method doc)

UnsafeRawPointer.toType():
Should it nit be something like typed(as:) instead 

Regards
LM
(From mobile)

> On Jun 24, 2016, at 3:40 AM, Andrew Trick via swift-evolution 
>  wrote:
> 
> I sent two RFC's for this proposal over the past couple months (see Early 
> swift-evolution threads). High-level feedback was fairly light. This version 
> is a final draft, as I expect it to go through the review process next week. 
> There is a lot more explanation and detail in this proposal now, and the 
> memory model has been simplified and clarified.
> 
> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md
> 
> If you have opinions or suggestions on API syntax, please make yourself 
> heard. You can jump straight to the naming discussion here:
> 
> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#variations-under-consideration
> 
> Of particular interest may be the API names for:
> 
> - Memory allocation/deallocation: fairly fundamental to the language.
> 
> - Unsafe casting from raw pointers to typed pointers. This is going to impact 
> a lot of code that needs C interoperability.
> 
> Keep in mind that we will make additive API improvements later for 
> convenience. We want the fundamentals to be clear, explicit, and reasonably 
> safe.
> 
> -Andy
> 
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

[David Sweeris via swift-evolution]

> On Jun 23, 2016, at 22:47, Félix Cloutier via swift-evolution 
>  wrote:
> 
> Thanks for answering my questions earlier. I like a lot of the changes.
> 
> Speaking of heterogeneous comparisons again, though, how are comparisons of 
> negative signed integers with unsigned integers handled?
> 
> Félix

I can't speak for anyone else, but I'd check the sign bit, return the correct 
answer if it's negative, and if not do an unsafeBitCast to the same-width 
unsigned type and use that to return the results of the homogeneous comparison.

There's probably a quicker way using some arcane bit-fiddling wizardry, but I 
don't know it off the top of my head.

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

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[L. Mihalkovic via swift-evolution]

Quick (semi) related question: any particular reason for .Type to be a 
contextual kwd rather than defined on a protocol? (No concrete def for 
metatypes?)
Regards
LM
(From mobile)

> On Jun 23, 2016, at 11:02 PM, Andrew Trick via swift-evolution 
>  wrote:
> 
> 
>>> On Jun 23, 2016, at 1:48 PM, Slava Pestov  wrote:
>>> 
>>> 
 On Jun 23, 2016, at 1:46 PM, Andrew Trick  wrote:
 
 
 On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution 
  wrote:
 
 The proposal is to change the type of self to always be Self, which can be 
 thought of as a special generic type parameter bound to the dynamic type 
 of the instance.
>>> 
>>> We’re currently specializing functions that take `self` as an argument. I 
>>> don’t think that will be possible after your proposed change.
>>> 
>>> - Andy
>> 
>> I’m not sure what that means. Do you currently punt on certain optimizations 
>> if a method returns ‘Self’?
>> 
>> It should be possible to keep the reified type information around, by 
>> passing in a metatype or something for example. Can you give a concrete code 
>> snippet demonstrating the optimization and how this change would inhibit it?
> 
> We bail out of generic specialization, inlining, and function signature 
> specialization when a type substitution contains dynamic self. 
> (hasDynamicSelfTypes). So, yes we currently almost entirely punt on 
> optimization for methods that return Self.
> 
> I don’t have an interesting case to point out. You can look into any trivial 
> example:
> 
> func foo(_: T) {}
> 
> func method() {
>   foo(self)
> }
> 
> -Andy
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Félix Cloutier via swift-evolution]

I'd like to point out that while NoReturn does indicate that the function can't 
return, this works because a function that can't return may well declare any 
return type that it likes, not necessarily just NoReturn.

It's confusing to see `@noreturn func foo() -> Int`, but it's not much better 
to have a `func foo() -> Int` that doesn't return either.

I don't think that `func foo() throws -> NoReturn` is much clearer either. Does 
foo always throw, does foo call exit, or does foo enter an endless loop?

It seems to me that we're only slightly moving the ambiguity, so I see no 
compelling reason to implement this proposal. That'll be a -1 here.

Félix

> Le 23 juin 2016 à 14:15:54, Jordan Rose via swift-evolution 
>  a écrit :
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
>  
> 
>  ]
> 
> I am already on record as being against this proposal:
> 
>> Just because it can be modelled as a type doesn’t mean it’s the best way to 
>> represent the concept. It feels like uniformity for uniformity’s sake.
>> 
>> func fatalError() -> NoReturn
>> 
>> @noreturn func fatalError()
>> 
>> The first one probably isn't too hard to explain to a learner. The second 
>> one probably doesn’t need an explanation.
> 
> (http://thread.gmane.org/gmane.comp.lang.swift.evolution/19958/ 
> )
> 
> A few more thoughts: I don't think uninhabited types actually come up very 
> often (though non-returning functions are also pretty rare). I'm not against 
> supporting composition for actual uninhabited types, but I don't think 
> composition of NoReturn/Never is particularly interesting. I don't find 
> throws compelling enough to add language support for it, but maybe I 
> just can't think of a case where you want to be generic over error types.
> 
> Jordan
> ___
> 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] [Discussion] A Problem With SE-0025?

[Jordan Rose via swift-evolution]

> On Jun 23, 2016, at 20:40, John McCall  wrote:
> 
>> On Jun 23, 2016, at 6:03 PM, Jordan Rose via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>> On Jun 15, 2016, at 18:47, Charles Srstka via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 On Jun 15, 2016, at 8:36 PM, Robert Widmann >>> > wrote:
 
 Point 3 is *not* how member lookup applies access control levels to 
 unannotated properties of outer structures (see 
 https://github.com/CodaFi/swift/blob/fb9f9536a5760369457d0f9c49599415cbc36e07/lib/Sema/TypeCheckDecl.cpp#L1470
  
 )
  and makes no sense.  They do not default to "internal" when unannotated, 
 they default to the highest possible access level they can get given the 
 decl they're in.  A private structure will necessarily have private 
 members.  This is the whole point of me raising this issue.  If we were to 
 break containment we would break the very motivation for this proposal.  
 And if we wish to do this to get this feature right, then the proposal 
 needs to be amended to include that kind of caveat.
>>> 
>>> This isn’t correct. If the outer type is marked “public”, and its 
>>> properties are not annotated, those properties will be internal, *not* 
>>> public, and you will not be able to see them outside of the module.
>>> 
>>> The rule can basically be summed up as “internal by default, unless we 
>>> can’t because our enclosing type is more restrictive than internal. Then, 
>>> be as visible as the enclosing type is.”
>> 
>> Robert is correct in the current interpretation: the default access level of 
>> a members is the access level of the enclosing type, except that nothing is 
>> ever public by default, and so you get ‘internal’ if the type is public. 
>> This suggests a rule that the access level of a member is never greater than 
>> the access level for a type, and the compiler will warn if you break this 
>> rule.
>> 
>> (Citation: I wrote both the implementation and the original proposal 
>>  for 
>> Swift access control. Please let’s not continue talking about the current 
>> (pre-SE-0025) behavior or its intent.)
>> 
>> —
>> 
>> As everyone has pointed out, this does not produce desirable behavior in the 
>> presence of the new ‘private’.
>> 
>> Here is my understanding of the problem:
>> 
>> - Blindly applying the current rules, the members of a ‘private' type 
>> default to being ‘private'.
>> - Blindly applying the current rules, the members of a ‘private' type cannot 
>> be marked as anything but ‘private’ or the compiler will warn.
>> 
>> (Thank you Robert for explaining the problem to me in person.)
>> 
>> —
> 
> Right.  I think the basic problem is that a rule mandating things by lexical 
> nesting cannot interwork successfully with an access level that is also based 
> on lexical nesting.
> 
>> I think Brent has done a great job of summing up the options with regard to 
>> ‘private’ on types:
>> 
>>> 1. Having an extra, unutterable access modifier that floats relative to the 
>>> other access levels.
>>> 
>>> 2. Having an extra access modifiers that floats relative to the other 
>>> access levels, but has a name (like `default`).
>>> 
>>> 3. Having an extra, unutterable access modifier between `fileprivate` and 
>>> `private`.
>>> 
>>> 4. Using `internal` whenever there's no access modifier, and not warning if 
>>> the effective scope is smaller.
>>> 
>>> 5. Having an extra access modifier between `fileprivate` and `private`, but 
>>> which has a name (like `inheritprivate`) 
>>> 
>>> 6. Changing the definition of `fileprivate` to be within the surrounding 
>>> private type if there is one, without changing the keyword.
>>> 
>>> 7. Changing the definition of `fileprivate` to be within the surrounding 
>>> private type if there is one, and changing the keyword to match.
>> 
>> 
>> (The order is Brent’s preferred order, with higher numbers being more 
>> preferred.)
> 
> Have you considered just removing this no-greater-access rule?  It seems kind 
> of low-value to me, certainly a worthy check for a linter or maybe a warning 
> but an unnecessarily pedantic check to be a hard error.  Just let the actual 
> visibility of a member be limited by the visibility of its context; you might 
> think that would regress diagnostics, but QoI here is pretty easy, e.g. 
> "cannot access member of a private extension from a different file" instead 
> of "cannot access private member from a different file".  As it is, you can't 
> just drop the visibility of a type without fixing all of its members.

It is just a warning already, but I think it’s a useful one: "you marked this 
thing public but the type isn’t, did you make a mistake?” Even with what little 
coding I get to do in

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol` syntax with `P1 & P2`

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
 

 ]

I’ve gone on record before as against this syntax, although when I set out 
earlier today to record my usual rebuttal I found that it really was mostly a 
matter of taste. Yes, this looks weird to me:

let callback: (Data) -> NSCoding & NSCopying

but I’m sure the infix ‘->’ for functions looked weird to everyone the first 
time they saw it as well, and it really is pretty clear in argument position.

However, I did remember one issue, which was brought up on the previous 
mega-thread: if we do want to generalize protocol values 
,
 we’re going to want something that’s essentially “a type with a ‘where’ 
clauses in it”. I really don’t want to force people to use a typealias to spell 
such a type, but at the same time I want that where clause to be clearly 
attached to the type. (As brought up before the return position of a function 
is currently ambiguous with SE-0081 
.)

Despite the lightweightedness and the well-prepared proposal by Adrian and 
Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
against the proposed syntax.

Jordan

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

[Félix Cloutier via swift-evolution]

Thanks for answering my questions earlier. I like a lot of the changes.

Speaking of heterogeneous comparisons again, though, how are comparisons of 
negative signed integers with unsigned integers handled?

Félix

> Le 23 juin 2016 à 17:36:14, Max Moiseev via swift-evolution 
>  a écrit :
> 
>> > For Integer, does the presence of signBit indicate an expectation that 
>> > signed Integers will have a two's complement representation?
>> Yes. That is correct.
>> 
>> So would this require a BigInt implementation to be in two's complement 
>> also? Most BigInt implementations use a separate sign I think, not sure if 
>> that's for performance reasons or merely convenience though.
> 
> 
> This is a very valid concern. I think I have discovered a truly marvelous 
> solution a way of addressing it:
> 
> `signBitIndex` is only used (I’m talking about the prototype now) to 
> determine the absolute required minimum of bits needed to represent the 
> current value of number when converting it to a different type.
> 
> So, instead of mentioning the sign bit, let’s call it what it is 
> ‘minimumRequiredWidth’ or something along this line. This move will also 
> allow the default implementation of `minimumRequiredWidth` to simply return 
> `bitWidth` for unsigned numbers and and `bitWidth - 1` for positive signed, 
> etc.
> 
> This way bignum implementations don’t have to have any specific underlying 
> representation. They can either inherit the default implementation or 
> implement their own version of `minimumRequiredWidth` in case the `bitWidth` 
> has some extra unused space that is not absolutely required.
> 
> I still need to validate this idea, these are just the thoughts. Any comments 
> are more than welcome.
> 
> Max
> 
> 
>> On Jun 23, 2016, at 3:19 PM, Patrick Pijnappel > > wrote:
>> 
>> - I remain unconvinced that defining an Arithmetic that includes both exact 
>> and floating-point numbers is a good idea. All of the arguments from Swift 1 
>> and 2 about why we didn't include this still seem relevant. To phrase it in 
>> generic programming terms, what algorithm would be generic over Arithmetic?
>> 
>> E.g. generic point/size/rect types.
>> 
>> > For Integer, does the presence of signBit indicate an expectation that 
>> > signed Integers will have a two's complement representation?
>> Yes. That is correct.
>> 
>> So would this require a BigInt implementation to be in two's complement 
>> also? Most BigInt implementations use a separate sign I think, not sure if 
>> that's for performance reasons or merely convenience though.
>> 
>> 
>> On Fri, Jun 24, 2016 at 7:40 AM, Jordan Rose via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Oh, one more comment: I suggest naming the primary protocol something other 
>> than "Integer", which IMHO is a little close to "Int" for a beginner. 
>> "Integral" is a bit too ambiguous, but maybe "IntegerArithmetic" or 
>> "ArithmeticInteger"? Or to go with the representation thing, 
>> "BinaryInteger"? (Some of the requirements are at odds with a decimal-based 
>> implementation.)
>> 
>> Jordan
>> 
>> 
>>> On Jun 23, 2016, at 13:50, Jordan Rose >> > wrote:
>>> 
>>> Hey, standard library folks. Glad we're doing this one. :-)
>>> 
>>> - I remain unconvinced that defining an Arithmetic that includes both exact 
>>> and floating-point numbers is a good idea. All of the arguments from Swift 
>>> 1 and 2 about why we didn't include this still seem relevant. To phrase it 
>>> in generic programming terms, what algorithm would be generic over 
>>> Arithmetic?
>>> 
>>> 
>>> - What is Integer.init(_:) supposed to do if the 
>>> floating-point value is larger than the maximum representable integer? 
>>> Smaller than the minimum? (As a special case, negative, when the integer 
>>> type is unsigned?) Infinity? NaN?
>>> 
>>> - Integer.init(_:) currently says "if it is representable". It 
>>> should say something like "trapping if it is not representable".
>>> 
>>> - I find it odd that Integer.init(clamping:) privileges the bounds of 
>>> fixed-width integers. I was going to suggest it should take a range to 
>>> clamp to that defaults to the min and max, but that's not implementable for 
>>> a BigInt.
>>> 
>>> - nthWord should count "from least-significant to most-significant" rather 
>>> than "from the right".
>>> 
>>> - As mentioned before, it sounds like Integer requires a two's complement 
>>> representation (if only so the result of nthWord can be interpreted 
>>> correctly). That should probably be in the doc comment for the protocol.
>>> 
>>> - Why is bitWidth in bits but nthWord in words? (I know there's a good 
>>> answer to this, but using them together seems like it will be common.)
>>> 
>>> - It's also probably worth calling out even more explicitly that bitWidth 
>>> is a representation property, not a value property. That is, a BigInt with 
>>> the value "1" could have a bitWidth of 1, 8, or

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

[John McCall via swift-evolution]

> On Jun 23, 2016, at 6:03 PM, Jordan Rose via swift-evolution 
>  wrote:
>> On Jun 15, 2016, at 18:47, Charles Srstka via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Jun 15, 2016, at 8:36 PM, Robert Widmann >> > wrote:
>>> 
>>> Point 3 is *not* how member lookup applies access control levels to 
>>> unannotated properties of outer structures (see 
>>> https://github.com/CodaFi/swift/blob/fb9f9536a5760369457d0f9c49599415cbc36e07/lib/Sema/TypeCheckDecl.cpp#L1470
>>>  
>>> )
>>>  and makes no sense.  They do not default to "internal" when unannotated, 
>>> they default to the highest possible access level they can get given the 
>>> decl they're in.  A private structure will necessarily have private 
>>> members.  This is the whole point of me raising this issue.  If we were to 
>>> break containment we would break the very motivation for this proposal.  
>>> And if we wish to do this to get this feature right, then the proposal 
>>> needs to be amended to include that kind of caveat.
>> 
>> This isn’t correct. If the outer type is marked “public”, and its properties 
>> are not annotated, those properties will be internal, *not* public, and you 
>> will not be able to see them outside of the module.
>> 
>> The rule can basically be summed up as “internal by default, unless we can’t 
>> because our enclosing type is more restrictive than internal. Then, be as 
>> visible as the enclosing type is.”
> 
> Robert is correct in the current interpretation: the default access level of 
> a members is the access level of the enclosing type, except that nothing is 
> ever public by default, and so you get ‘internal’ if the type is public. This 
> suggests a rule that the access level of a member is never greater than the 
> access level for a type, and the compiler will warn if you break this rule.
> 
> (Citation: I wrote both the implementation and the original proposal 
>  for Swift 
> access control. Please let’s not continue talking about the current 
> (pre-SE-0025) behavior or its intent.)
> 
> —
> 
> As everyone has pointed out, this does not produce desirable behavior in the 
> presence of the new ‘private’.
> 
> Here is my understanding of the problem:
> 
> - Blindly applying the current rules, the members of a ‘private' type default 
> to being ‘private'.
> - Blindly applying the current rules, the members of a ‘private' type cannot 
> be marked as anything but ‘private’ or the compiler will warn.
> 
> (Thank you Robert for explaining the problem to me in person.)
> 
> —

Right.  I think the basic problem is that a rule mandating things by lexical 
nesting cannot interwork successfully with an access level that is also based 
on lexical nesting.

> I think Brent has done a great job of summing up the options with regard to 
> ‘private’ on types:
> 
>> 1. Having an extra, unutterable access modifier that floats relative to the 
>> other access levels.
>> 
>> 2. Having an extra access modifiers that floats relative to the other access 
>> levels, but has a name (like `default`).
>> 
>> 3. Having an extra, unutterable access modifier between `fileprivate` and 
>> `private`.
>> 
>> 4. Using `internal` whenever there's no access modifier, and not warning if 
>> the effective scope is smaller.
>> 
>> 5. Having an extra access modifier between `fileprivate` and `private`, but 
>> which has a name (like `inheritprivate`) 
>> 
>> 6. Changing the definition of `fileprivate` to be within the surrounding 
>> private type if there is one, without changing the keyword.
>> 
>> 7. Changing the definition of `fileprivate` to be within the surrounding 
>> private type if there is one, and changing the keyword to match.
> 
> 
> (The order is Brent’s preferred order, with higher numbers being more 
> preferred.)

Have you considered just removing this no-greater-access rule?  It seems kind 
of low-value to me, certainly a worthy check for a linter or maybe a warning 
but an unnecessarily pedantic check to be a hard error.  Just let the actual 
visibility of a member be limited by the visibility of its context; you might 
think that would regress diagnostics, but QoI here is pretty easy, e.g. "cannot 
access member of a private extension from a different file" instead of "cannot 
access private member from a different file".  As it is, you can't just drop 
the visibility of a type without fixing all of its members.

Otherwise I agree that 6 and 4 are reasonable ways of talking about it.

John.

> 
> If the discussion on SE-0025 is any indication, it’s that Naming Is Hard and 
> that I really don’t want to come up with a new name at this point. Therefore, 
> my preferred solution is (6), followed by (4). The concrete change to the 
> rules I outlined above would be as follows:
> 
> - The defa

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[L. Mihalkovic via swift-evolution]

Inline
Regards
(From mobile)
> On Jun 23, 2016, at 10:13 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> L. Mihalkovic via swift-evolution  writes:
> 
>> Has a meta-circular syntax been considered for the precedence group
> definitions? Aside from limiting the
>> proliferation of new keywords, it would also make them discoverable by
> reflection when the api gets added
>> in 4.0. My apologies if it was already discarded.
>> Regards
>> LM
> 
> Could you please explain what you mean by "meta-circular syntax for the 
> precedence group definitions"? An example?
=define it using existing swift constructs rather than by extending swift with 
new kwd looks like grp matches a struct. 
> ___
> 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] [Proposal] Remove Boolean

[Chris Lattner via swift-evolution]

> On Jun 23, 2016, at 3:38 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> It does abstract over DarwinBoolean as well, but this still seems reasonable 
> to me. The most common cases to encounter ObjCBool and DarwinBoolean are 
> out-parameters (which you are usually setting rather than reading, and they 
> will remain BooleanLiteralConvertible) and imported struct fields (which are 
> fairly rare). And John McCall has some ideas for how to even eliminate the 
> latter, though I think that can be separated from this proposal.

Right.

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

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

[Brandon Knope via swift-evolution]

Maybe something like this?

let calendar = Calendar.current()

for date in dates where calendar.isDateInToday(date) {
//process date only in today
}

VS.

for date in dates {
guard calendar.isDateInToday(date) else { continue }

}

The where keeps the body of the for loop uncluttered so it can focus *just* on 
what's important: processing dates that are only in a certain day.

Also, let's pretend someone comes along later and decides to add some code to 
this loop:

for date in dates {
/** Anything here is using an untested date **/
/** Some programmer comes along later and adds unrelated 
   * date handling code...or mistakenly adds code here **/

guard calendar.isDateInToday(date) else { continue }
}

The where tells that this loop was intended to only deal with certain dates and 
enforces it. Guard only guards against it if code is added after it.

With the where clause it is:
- self-documenting
- must be changed if you want a different behavior, preventing unintended 
mistakes later

I don't want to say this is a "more" challenging example of filtering, but I do 
think it can show its expressiveness.

Brandon

Sent from my iPad

> On Jun 23, 2016, at 10:14 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 23, 2016, at 7:34 PM, William Shipley via swift-evolution 
>>  wrote:
>> 
>> I’m against removing “where" from “for/in”. I use it in my code and I think 
>> it aids readability quite a bit. In the example:
>> 
>> for x in theArray where x % 2 == 1 { print (x) }
> I have used odd-even examples a lot when presenting this concept, and 
> inevitably the response
> is "Whoa, that's cool". What I'm missing are more challenging real-world 
> use-cases to justify 
> the construct, and an exploration of why the challenging cases would not need 
> debugger 
> support at that point.
> 
> My concern (and I am happy to be corrected) is that any code that becomes 
> slightly more 
> complex loses the beauty and readability and hinders debugging at the same 
> time.
> 
> -- E
> 
> ___
> 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] SE-0105: Removing Where Clauses from For-In Loops

[Erica Sadun via swift-evolution]

> On Jun 23, 2016, at 7:34 PM, William Shipley via swift-evolution 
>  wrote:
> 
> I’m against removing “where" from “for/in”. I use it in my code and I think 
> it aids readability quite a bit. In the example:
> 
> for x in theArray where x % 2 == 1 { print (x) }
I have used odd-even examples a lot when presenting this concept, and 
inevitably the response
is "Whoa, that's cool". What I'm missing are more challenging real-world 
use-cases to justify 
the construct, and an exploration of why the challenging cases would not need 
debugger 
support at that point.

My concern (and I am happy to be corrected) is that any code that becomes 
slightly more 
complex loses the beauty and readability and hinders debugging at the same time.

-- E

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

Re: [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

[Dany St-Amant via swift-evolution]

> Le 23 juin 2016 à 00:12, Chris Lattner via swift-evolution 
>  a écrit :
> 
> Hello Swift community,
> 
> The review of "SE-0105: Removing Where Clauses from For-In Loops" begins now 
> and runs through June 29. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md
> 

>* What is your evaluation of the proposal?

+0.5

The 'where' is a nice sugar for people familiar with SQL but doesn't seem to 
hold its ground. Without 'where' nor 'guard', something like:

for element in collection where condition(element) { doSomething(element) }

is/could be

for element in collection { if condition(element) { doSomething(element) } }

Beside the extra curly brace there isn't much difference in the clarity of the 
message, rendering the sugar not as sweet as it sound.

Also the 'where' is not available to the other loop structure: 'while', 
'repeat', 'do'. For these one have to rely on 'if' and 'guard'. "Forcing" the 
use of 'if' and 'guard' in all loop structure would provide uniformity.

The fix-it should probably used the nested 'for { if { } }' as its the syntax 
matching more closely what was written, at the cost of one ident level, and 
missing an opportunity to advertise a usage of 'guard'

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

No, 'where' is not confusing; it's the 'while binding where' and the 'for .. In 
infiniteSequence where ..' which are.
Yes, 'where' (in 'for .. in') is pointless and if it did not currently exist 
would likely never be approved as an addition to the language due to its narrow 
field of operation.

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

'for .. in .. where'
Has a Swift like syntax
Is a sugar with limited scope which doesn't pull its weight, so is not Swift 
like

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

Never used 'where' attached to directly to a loop.
Extensive use of SQL-like queries.

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

Closely followed the thread as I originally feared the disappearance of this 
nice construct. Tried and failed to understand how the syntax can be seen as 
confusing.

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

Re: [swift-evolution] [Review] SE-0103: Make non-escaping closures the default

[Brent Royal-Gordon via swift-evolution]

>   * What is your evaluation of the proposal?

I support it; if escaping and nonescaping are about equally common, but users 
would never discover a @nonescaping on their own, I think it makes sense to 
have @escaping instead.

However, I'm concerned about migration. Rather than saying that all currently 
escaping closures will be marked with @escaping, the proposal says:

> Existing code using the @noescape attribute will need to be migrated to 
> remove the attribute since it will be the default. In addition, the compiler 
> will need to detect escaping closures that are not marked with @escaping and 
> create an error with a fixit to add the required attribute.

If I'm reading this correctly, it's saying that the migrator will convert *all* 
closures into nonescaping closures and then let compiler errors guide the user 
to convert those that need to escape. This is going to add to the burden of 
migrating code to Swift 3. And the compiler may not catch all 
mistakes—consider, for instance, a framework which defines a public delegate 
protocol with a method that takes a completion or reply closure. That parameter 
probably ought to be @escaping, but if it's not, nothing in the module itself 
will break.

I think it would be better if the migrator added @escaping to all 
currently-non-@noescape closures, thus preserving current semantics. The cost 
of doing so—forgoing a speed improvement—is just not that large. And I can just 
imagine the tableflip I would do if I were assigned to migrate, say, Alamofire 
to Swift 3 and it forced me to manually annotate *every* closure parameter in 
the entire library.

Failing that, I would consider at least doing so on public methods of protocols 
and nonfinal classes, where the concerns are most acute. I would also like to 
see the migrator automatically add @escaping to closure parameters it 
heuristically determines are probably escaping—at the very least, `completion` 
and `completionHandler` trailing closures.

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

Yes.

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

Yes. @noescape was just weird.

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

None I can think of, unless Objective-C is somehow doing this behind my back.

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

Quick reading.

-- 
Brent Royal-Gordon
Architechies

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

[swift-evolution] [Draft] UnsafeRawPointer API

[Andrew Trick via swift-evolution]

I sent two RFC's for this proposal over the past couple months (see Early 
swift-evolution threads). High-level feedback was fairly light. This version is 
a final draft, as I expect it to go through the review process next week. There 
is a lot more explanation and detail in this proposal now, and the memory model 
has been simplified and clarified.

https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md

If you have opinions or suggestions on API syntax, please make yourself heard. 
You can jump straight to the naming discussion here:

https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#variations-under-consideration

Of particular interest may be the API names for:

- Memory allocation/deallocation: fairly fundamental to the language.

- Unsafe casting from raw pointers to typed pointers. This is going to impact a 
lot of code that needs C interoperability.

Keep in mind that we will make additive API improvements later for convenience. 
We want the fundamentals to be clear, explicit, and reasonably safe.

-Andy

# UnsafeRawPointer API

* Proposal: [SE-](https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md)
* Author(s): [Andrew Trick](https://github.com/atrick)
* Status: **[Awaiting review](#rationale)**
* Review manager: TBD

For quick reference, jump to:
- [Full UnsafeRawPointer API](#full-unsaferawpointer-api)

Contents:
- [Introduction](#introduction)
- [Proposed Solution](#proposed-solution)
- [Motivation](#motivation)
- [Memory model explanation](#memory-model-explanation)
- [Expected use cases](#expected-use-cases)
- [Detailed design](#detailed-design)
- [Impact on existing code](#impact-on-existing-code)
- [Implementation status](#implementation-status)
- [Future improvements and planned additive API](#future-improvements-and-planned-additive-api)
- [Variations under consideration](#variations-under-consideration)
- [Alternatives previously considered](#alternatives-previously-considered)

## Introduction

Swift enforces type safe access to memory and follows strict aliasing
rules. However, code that uses unsafe APIs or imported types can
circumvent the language's natural type safety. Consider the following
example of *type punning* using the ``UnsafePointer`` type::

```swift
  let ptrT: UnsafeMutablePointer = ...
  // Store T at this address.
  ptrT[0] = T()
  // Load U at this address
  let u = UnsafePointer(ptrT)[0]
```

This code violates assumptions made by the compiler and falls into the
category of "undefined behavior". Undefined behavior is a way of
saying that we cannot easily specify constraints on the behavior of
programs that violate a rule. The program may crash, corrupt memory,
or be miscompiled in other ways. Miscompilation may include optimizing
away code that was expected to execute or executing code that was not
expected to execute.

Swift already protects against undefined behavior as long as the code
does not use "unsafe" constructs. However, UnsafePointer is an
important API for interoperability and building high performance data
structures. As such, the rules for safe, well-defined usage of the API
should be clear. Currently, it is too easy to use UnsafePointer
improperly. For example, innocuous argument conversion such as this
could lead to undefined behavior:

```swift
func takesUIntPtr(_ p: UnsafeMutablePointer) -> UInt {
  return p[0]
}
func takesIntPtr(q: UnsafeMutablePointer) -> UInt {
  return takesUIntPtr(UnsafeMutablePointer(q))
}

```

Furthermore, no API currently exists for accessing raw, untyped
memory. `UnsafePointer` and `UnsafeMutablePointer`
refer to a typed region of memory, and the compiler assumes that the
element type (`Pointee`) is consistent with other access to the same
memory. For details of the compiler's rules for memory aliasing,
see [proposed Type Safe Memory Access documentation][1]. Making
`UnsafePointer` safer requires introducing a new pointer type that is
not bound by the same strict aliasing rules.

This proposal aims to achieve several goals in one coherent design:

1. Provide an untyped pointer type.
 
2. Specify which pointer types follow strict aliasing rules.

3. Inhibit UnsafePointer conversion that violates strict aliasing.

4. Provide an API for safe type punning (memcpy semantics).

5. Provide an API for manual memory layout (bytewise pointer arithmetic).

Early swift-evolution threads:

- [\[RFC\] UnsafeBytePointer API for In-Memory Layout](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/thread.html#16909)

- [\[RFC\] UnsafeBytePointer API for In-Memory Layout (Round 2)](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/thread.html#18156)

[1]:https://github.com/atrick/swift/blob/type-safe-mem-docs/docs/TypeSafeMemory.rst

Mentions of `UnsafePointer` that appear in this document's prose also
apply to `UnsafeMutablePointer`.

## Proposed Solution

We first introd

[swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

[William Shipley via swift-evolution]

I’m against removing “where" from “for/in”. I use it in my code and I think it 
aids readability quite a bit. In the example:

for x in theArray where x % 2 == 1 { print (x) }
I think it’s artificially confusing because the print is on the same line. If 
we break the line we see the “where” at the end of the line and it reads like 
the English I would use to tell someone what this loop is doing:

for x in theArray where x % 2 == 1 {
... 
To me this reads very clearly: I’m looping through some values BUT I want to 
skip some, now here’s what I’m going to do with these values. Using “guard” for 
this purpose adds unnecessary lines of code and also allows for the (common in 
my experience!) bug of accidentally using “break” or “return” inside the guard 
instead of “continue”. Also, guard / continue just doesn’t read like a filter.

Having the filtering/where logic (eg: what I’m _iterating_ over) separated from 
the body of the loop (eg: what i’m _doing_ to those objects) is one of my 
favorite things about Swift.

Yes, we could also do that with “filter” followed by “forEach”, but then it 
would read totally backwards and I don’t always want that. (I mean, at this 
point “for/in blah” could be considered syntactic sugar for "blah.forEach {}” 
but I still want "for/in".)


for x in theArray where x % 2 == 1 { print (x) }
while let x = anArray.popLast() where x % 2 == 1 { print(x) }
In this example case the “while” is only unclear to me because Swift has the 
odd thing where it does pattern matching using “let” as well as using let in a 
plain old assignment, and it’s hard to know which is which. I could argue that 
it’s also unclear why I can’t type “let x = anArray popLast where x % 2 == 1” 
by itself on a line and have x be an optional. (I would have liked it if we 
used “match” as a keyword instead of “let” when we’re doing patterns, but there 
you go.)

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

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

[Jordan Rose via swift-evolution]

> On Jun 15, 2016, at 18:47, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Jun 15, 2016, at 8:36 PM, Robert Widmann > > wrote:
>> 
>> Point 3 is *not* how member lookup applies access control levels to 
>> unannotated properties of outer structures (see 
>> https://github.com/CodaFi/swift/blob/fb9f9536a5760369457d0f9c49599415cbc36e07/lib/Sema/TypeCheckDecl.cpp#L1470
>>  
>> )
>>  and makes no sense.  They do not default to "internal" when unannotated, 
>> they default to the highest possible access level they can get given the 
>> decl they're in.  A private structure will necessarily have private members. 
>>  This is the whole point of me raising this issue.  If we were to break 
>> containment we would break the very motivation for this proposal.  And if we 
>> wish to do this to get this feature right, then the proposal needs to be 
>> amended to include that kind of caveat.
> 
> This isn’t correct. If the outer type is marked “public”, and its properties 
> are not annotated, those properties will be internal, *not* public, and you 
> will not be able to see them outside of the module.
> 
> The rule can basically be summed up as “internal by default, unless we can’t 
> because our enclosing type is more restrictive than internal. Then, be as 
> visible as the enclosing type is.”

Robert is correct in the current interpretation: the default access level of a 
members is the access level of the enclosing type, except that nothing is ever 
public by default, and so you get ‘internal’ if the type is public. This 
suggests a rule that the access level of a member is never greater than the 
access level for a type, and the compiler will warn if you break this rule.

(Citation: I wrote both the implementation and the original proposal 
 for Swift 
access control. Please let’s not continue talking about the current 
(pre-SE-0025) behavior or its intent.)

—

As everyone has pointed out, this does not produce desirable behavior in the 
presence of the new ‘private’.

Here is my understanding of the problem:

- Blindly applying the current rules, the members of a ‘private' type default 
to being ‘private'.
- Blindly applying the current rules, the members of a ‘private' type cannot be 
marked as anything but ‘private’ or the compiler will warn.

(Thank you Robert for explaining the problem to me in person.)

—

I think Brent has done a great job of summing up the options with regard to 
‘private’ on types:

> 1. Having an extra, unutterable access modifier that floats relative to the 
> other access levels.
> 
> 2. Having an extra access modifiers that floats relative to the other access 
> levels, but has a name (like `default`).
> 
> 3. Having an extra, unutterable access modifier between `fileprivate` and 
> `private`.
> 
> 4. Using `internal` whenever there's no access modifier, and not warning if 
> the effective scope is smaller.
> 
> 5. Having an extra access modifier between `fileprivate` and `private`, but 
> which has a name (like `inheritprivate`) 
> 
> 6. Changing the definition of `fileprivate` to be within the surrounding 
> private type if there is one, without changing the keyword.
> 
> 7. Changing the definition of `fileprivate` to be within the surrounding 
> private type if there is one, and changing the keyword to match.


(The order is Brent’s preferred order, with higher numbers being more 
preferred.)

If the discussion on SE-0025 is any indication, it’s that Naming Is Hard and 
that I really don’t want to come up with a new name at this point. Therefore, 
my preferred solution is (6), followed by (4). The concrete change to the rules 
I outlined above would be as follows:

- The default level of members is ‘fileprivate’ for a private or fileprivate 
type, and ‘internal’ for an internal or public type.
- Any rule where something must be “as visible as the type” (such as minimum 
access for required initializers) must be ‘fileprivate’ for a private type 
(rather than private).
- As a consequence, the compiler will warn when the access level of a member is 
“too high”; that is, where the next level down wouldn’t change anything.

Note that there don’t actually need to be any changes to access rules to make 
this work; when a type is private, there won’t be any uses of it outside of the 
enclosing scope, and so nobody elsewhere in the file will be able to call one 
of those fileprivate members.

—

Ilya hasn’t been active on swift-evolution lately, so if no one has serious 
objections to (6) besides “I don’t like the name” Robert and I will write up an 
official amendment to SE-0025 and take it to Doug or Chris. If they think this 
is not a good idea to just move forward with, I’ll ask them whether they’d 
prefer a partial implementation that disallows ‘private’ on nominal 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

[Max Moiseev via swift-evolution]

> > For Integer, does the presence of signBit indicate an expectation that 
> > signed Integers will have a two's complement representation?
> Yes. That is correct.
> 
> So would this require a BigInt implementation to be in two's complement also? 
> Most BigInt implementations use a separate sign I think, not sure if that's 
> for performance reasons or merely convenience though.


This is a very valid concern. I think I have discovered a truly marvelous 
solution a way of addressing it:

`signBitIndex` is only used (I’m talking about the prototype now) to determine 
the absolute required minimum of bits needed to represent the current value of 
number when converting it to a different type.

So, instead of mentioning the sign bit, let’s call it what it is 
‘minimumRequiredWidth’ or something along this line. This move will also allow 
the default implementation of `minimumRequiredWidth` to simply return 
`bitWidth` for unsigned numbers and and `bitWidth - 1` for positive signed, etc.

This way bignum implementations don’t have to have any specific underlying 
representation. They can either inherit the default implementation or implement 
their own version of `minimumRequiredWidth` in case the `bitWidth` has some 
extra unused space that is not absolutely required.

I still need to validate this idea, these are just the thoughts. Any comments 
are more than welcome.

Max


> On Jun 23, 2016, at 3:19 PM, Patrick Pijnappel  
> wrote:
> 
> - I remain unconvinced that defining an Arithmetic that includes both exact 
> and floating-point numbers is a good idea. All of the arguments from Swift 1 
> and 2 about why we didn't include this still seem relevant. To phrase it in 
> generic programming terms, what algorithm would be generic over Arithmetic?
> 
> E.g. generic point/size/rect types.
> 
> > For Integer, does the presence of signBit indicate an expectation that 
> > signed Integers will have a two's complement representation?
> Yes. That is correct.
> 
> So would this require a BigInt implementation to be in two's complement also? 
> Most BigInt implementations use a separate sign I think, not sure if that's 
> for performance reasons or merely convenience though.
> 
> 
> On Fri, Jun 24, 2016 at 7:40 AM, Jordan Rose via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Oh, one more comment: I suggest naming the primary protocol something other 
> than "Integer", which IMHO is a little close to "Int" for a beginner. 
> "Integral" is a bit too ambiguous, but maybe "IntegerArithmetic" or 
> "ArithmeticInteger"? Or to go with the representation thing, "BinaryInteger"? 
> (Some of the requirements are at odds with a decimal-based implementation.)
> 
> Jordan
> 
> 
>> On Jun 23, 2016, at 13:50, Jordan Rose > > wrote:
>> 
>> Hey, standard library folks. Glad we're doing this one. :-)
>> 
>> - I remain unconvinced that defining an Arithmetic that includes both exact 
>> and floating-point numbers is a good idea. All of the arguments from Swift 1 
>> and 2 about why we didn't include this still seem relevant. To phrase it in 
>> generic programming terms, what algorithm would be generic over Arithmetic?
>> 
>> 
>> - What is Integer.init(_:) supposed to do if the 
>> floating-point value is larger than the maximum representable integer? 
>> Smaller than the minimum? (As a special case, negative, when the integer 
>> type is unsigned?) Infinity? NaN?
>> 
>> - Integer.init(_:) currently says "if it is representable". It 
>> should say something like "trapping if it is not representable".
>> 
>> - I find it odd that Integer.init(clamping:) privileges the bounds of 
>> fixed-width integers. I was going to suggest it should take a range to clamp 
>> to that defaults to the min and max, but that's not implementable for a 
>> BigInt.
>> 
>> - nthWord should count "from least-significant to most-significant" rather 
>> than "from the right".
>> 
>> - As mentioned before, it sounds like Integer requires a two's complement 
>> representation (if only so the result of nthWord can be interpreted 
>> correctly). That should probably be in the doc comment for the protocol.
>> 
>> - Why is bitWidth in bits but nthWord in words? (I know there's a good 
>> answer to this, but using them together seems like it will be common.)
>> 
>> - It's also probably worth calling out even more explicitly that bitWidth is 
>> a representation property, not a value property. That is, a BigInt with the 
>> value "1" could have a bitWidth of 1, 8, or 128.
>> 
>> - What does signBitIndex return if self is positive? I ask because it's just 
>> not in the doc comment, but thinking about the answer made it obvious that 
>> the correct return value for 0 is 0.
>> 
>> - For signed integers, does remainder(dividingBy:) have specified behavior 
>> for the sign of the result? See 
>> https://en.wikipedia.org/wiki/Modulo_operation 
>> .
>> 
>> - I do think having Swif

Re: [swift-evolution] [Pitch] Add Null struct to Foundation

[Michael Peternell via swift-evolution]

I think NSNull() should be used, not a struct. I don't think that a struct 
would be more performant. Or maybe the performance doesn't matter at all in any 
real-world usage scenario. But you may write a benchmark of a realistic (!) 
use-case (!) if you think otherwise... would be interesting to see the results.

Keeping with NSNull() also simplifies objc-interoperability.

-Michael

> Am 23.06.2016 um 06:14 schrieb Alsey Miller via swift-evolution 
> :
> 
> Add a struct Null to the Swift 3.0 Foundation value types. As a struct, Null 
> is more performant (no ARC or memory allocation) than NSNull, and will be 
> needed for Swift JSON decoders and libraries that want to use struct value 
> types, and be free from classes for their model layer.
> 
> 
>   Coleman,
> 
> 
> 
> 
> 
> ___
> 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] [Review] SE-0104: Protocol-oriented integers

[Jordan Rose via swift-evolution]

> On Jun 23, 2016, at 14:38, Nicola Salmoria via swift-evolution 
>  wrote:
> 
> Max Moiseev via swift-evolution  writes:
> 
>>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under
> what situations would
>> you have an overflow? I could only come up with something like
> Int.min.dividedWithOverflow(-1).
>> If you look at the prototype here:
>> 
> https://github.com/apple/swift/blob/master/test/Prototypes
> /Integers.swift.gyb#L789
>> there is
>> exactly the check that you’ve mentioned, but for all signed integers.
> Besides, it is very convenient to
>> have all the arithmetic operations be implemented the same way, even if
> there were no real overflows for division.
> 
> I agree with this for the four basic operations, but not for the remainder
> operation.
> 
> By definition, the remainder is always strictly smaller (in absolute value)
> than the divisor, so even if the division itself overflows, the remainder
> must be representable, so technically it never overflow.
> 
> In the only actual case where the division overflow, that is Int.min / -1,
> the remainder is simply 0.
> 
> For these reasons, I think it would make sense to explicitly request that
> the remainder operation never traps, and remove the overflow variants.

…except when taking a remainder dividing by 0, right?

Jordan

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

[Jordan Rose via swift-evolution]

> On Jun 23, 2016, at 15:35, Max Moiseev  wrote:
> 
> Hi Jordan,
> 
>> On Jun 23, 2016, at 1:50 PM, Jordan Rose > > wrote:
>> 
>> Hey, standard library folks. Glad we're doing this one. :-)
>> 
>> - I remain unconvinced that defining an Arithmetic that includes both exact 
>> and floating-point numbers is a good idea. All of the arguments from Swift 1 
>> and 2 about why we didn't include this still seem relevant. To phrase it in 
>> generic programming terms, what algorithm would be generic over Arithmetic?
> Steve, I don’t remember exactly why we chose to do it this time. Can you 
> answer?
> 
>> 
>> - What is Integer.init(_:) supposed to do if the 
>> floating-point value is larger than the maximum representable integer? 
>> Smaller than the minimum? (As a special case, negative, when the integer 
>> type is unsigned?) Infinity? NaN?
> The same thing it does now — trap.

I think this is worth calling out as a precondition: the value must be within 
the bounds of the integer type. (The implementation may not trap for some 
values slightly outside the integer type, like 0.1 being converted to UInt, but 
it's still not defined.)


>> 
>> - Integer.init(_:) currently says "if it is representable". It 
>> should say something like "trapping if it is not representable”.
> There is a comment saying that this is the precondition that must be checked 
> by the caller. The initializer will trap but this is the implementation 
> detail, isn’t it?

Ah, of course. My bad.


>> 
>> - I find it odd that Integer.init(clamping:) privileges the bounds of 
>> fixed-width integers. I was going to suggest it should take a range to clamp 
>> to that defaults to the min and max, but that's not implementable for a 
>> BigInt.
> It is always possible to pass bounds as an optional value and default to 
> min…max in .none case.
> So you are suggesting something like `init(clamping: T, within 
> bounds: Optional> = nil)` then?
> I don’t disagree. Looks useful, but I cannot imagine a good real world use 
> for it, except for:
> 
> extension Integer {
>   public func findClosest(to: Self, within bounds: ClosedRange) {
> return Self(clamping: to, within: bounds)
>   }
> }

I don't find it any different from the existing requirement. If I'm going from 
a potentially large (absolute) value to a smaller one, it's possible I only 
care about representation, but it's also possible I have a smaller type here 
because of context.

englishPluralIndex = items.count.clamped(to: 0...2)

Maybe I'd go the other way, and say that this isn't a useful requirement. Are 
there algorithms that need this that are generic over Integer? (rather than 
FixedWidthInteger)



> 
>> 
>> - nthWord should count "from least-significant to most-significant" rather 
>> than "from the right”.
> Will this definition work fine with different endiannesses? It needs some 
> thinking, but I see your point.

Yes, "significant" always refers to place values, not to the representation in 
memory/registers.

>> - Why is bitWidth in bits but nthWord in words? (I know there's a good 
>> answer to this, but using them together seems like it will be common.)
> There is a derived property that will return the width in words based on 
> bitWidth and word size.

Got it. May be deserving of a SeeAlso.

>> 
>> - Why are bitwise operations limited to fixed-width integers? I see "The 
>> only difference is that because shifting left truncates the high bits of 
>> fixed-width integers, it is hard to define what a left shift would mean to 
>> an arbitrary-precision integer" further down, but I would just assume it 
>> wouldn't truncate (i.e. it would be a pure multiplication by two).
> Exactly. It won’t truncate and we considered it to be a sufficient difference 
> in behavior to not allow it to be used in the context over all integers.

Hm. I guess that makes sense. My interpretation: the behavior on fixed-width 
integers is well-understood, the behavior on arbitrary-precision integers is 
easy to understand, but the behavior in an algorithm generic over both might be 
problematic. Thanks for the explanation.


>> 
>> - Is there a requirement about left-shifting into the sign bit, for '<<' and 
>> for '&<<‘?
> The current behavior is to not do anything special about the sign bit. So 
> that (64 as Int8) << 1 would result in a -128.
> 
> I should probably add a general note somewhere in the proposal that “unless 
> specifically mentioned, the behavior will remain consistent with the existing 
> implementation”.

Sure. In this case I was asking about the requirement, though. If I use 
something like llvm::APSInt, which has an arbitrary-but-fixed-at-creation 
number of words, does shifting into the sign bit of a signed integer always 
result in a negative number? It never traps or is assumed not to happen?


> 
>> 
>> - What is the ArithmeticOverflow type?
> It is an enum with 2 cases, just like Optional<()>, but with more specific 
> case name. If not fo

Re: [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

[Haravikk via swift-evolution]

> On 23 Jun 2016, at 05:12, Chris Lattner via swift-evolution 
>  wrote:
> 
>   * What is your evaluation of the proposal?

I'm against it. While I sympathise with some of the reasons behind it, I feel 
there are better solutions than removing this feature, and that at the very 
least doing so now would be premature as we have yet to see how removing where 
from conditionals will impact people's grasp of it on for loops. (currently 
confusion stems from the ambiguity compared to while where).
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

I don't believe so; I think that the justification for removing the feature 
needs to be stronger than it is, and that other solutions may have better merit.

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

I feel not; personally I find where more Swift-y than using .filter() or 
if/guard continue, but this appears to be highly subjective.

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

Participated quite a bit in the discussion.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Remove Boolean

[Jordan Rose via swift-evolution]

It does abstract over DarwinBoolean as well, but this still seems reasonable to 
me. The most common cases to encounter ObjCBool and DarwinBoolean are 
out-parameters (which you are usually setting rather than reading, and they 
will remain BooleanLiteralConvertible) and imported struct fields (which are 
fairly rare). And John McCall has some ideas for how to even eliminate the 
latter, though I think that can be separated from this proposal.

Jordan


> On Jun 23, 2016, at 14:33, Anton Zhilin via swift-evolution 
>  wrote:
> 
> Following goals of Swift 3, I've prepaired a minimalistic proposal to 
> remove Boolean protocol.
> 
> https://github.com/Anton3/swift-evolution/blob/remove-
> boolean/proposals/-remove-boolean.md
> 
> ## Introduction
> 
> Remove `Boolean` protocol. Only Bool will be able to be used in logical 
> contexts:
> 
> let x: ObjCBool = true
> if x {  // will become an error!
>  ...
> }
> 
> ## Motivation
> 
> "Boolean" isn't pulling its weight:
> - It only abstracts over Bool and ObjCBool.
> - It only enables a few operations on ObjCBool, which are not very 
> important.
> - ObjCBool is a bridging problem, and we don't handle bridging by 
> introducing common protocols (e.g. in the case of String vs NSString, we 
> don't introduce a common "Stringable" protocol.
> 
> Further, it complicates the model:
> - People are confused by it and the similar but very different Bool 
> type.
> - Bool is a simple enough concept to not need a family of protocols.
> 
> ## Impact on existing code
> 
> Change is backwards incompatible, but automatic migration is possible:
> 
> - In places where Boolean (but not Bool) was in logical contexts, 
> migrator can add `.boolValue`
> - Migrator can remove conformances to Boolean
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

[Max Moiseev via swift-evolution]

Hi Jordan,

> On Jun 23, 2016, at 1:50 PM, Jordan Rose  wrote:
> 
> Hey, standard library folks. Glad we're doing this one. :-)
> 
> - I remain unconvinced that defining an Arithmetic that includes both exact 
> and floating-point numbers is a good idea. All of the arguments from Swift 1 
> and 2 about why we didn't include this still seem relevant. To phrase it in 
> generic programming terms, what algorithm would be generic over Arithmetic?
Steve, I don’t remember exactly why we chose to do it this time. Can you answer?

> 
> - What is Integer.init(_:) supposed to do if the 
> floating-point value is larger than the maximum representable integer? 
> Smaller than the minimum? (As a special case, negative, when the integer type 
> is unsigned?) Infinity? NaN?
The same thing it does now — trap.

> 
> - Integer.init(_:) currently says "if it is representable". It 
> should say something like "trapping if it is not representable”.
There is a comment saying that this is the precondition that must be checked by 
the caller. The initializer will trap but this is the implementation detail, 
isn’t it?
> 
> - I find it odd that Integer.init(clamping:) privileges the bounds of 
> fixed-width integers. I was going to suggest it should take a range to clamp 
> to that defaults to the min and max, but that's not implementable for a 
> BigInt.
It is always possible to pass bounds as an optional value and default to 
min…max in .none case.
So you are suggesting something like `init(clamping: T, within 
bounds: Optional> = nil)` then?
I don’t disagree. Looks useful, but I cannot imagine a good real world use for 
it, except for:

extension Integer {
  public func findClosest(to: Self, within bounds: ClosedRange) {
return Self(clamping: to, within: bounds)
  }
}

> 
> - nthWord should count "from least-significant to most-significant" rather 
> than "from the right”.
Will this definition work fine with different endiannesses? It needs some 
thinking, but I see your point.
> 
> - As mentioned before, it sounds like Integer requires a two's complement 
> representation (if only so the result of nthWord can be interpreted 
> correctly). That should probably be in the doc comment for the protocol.
I’ll add it. Thanks.
> 
> - Why is bitWidth in bits but nthWord in words? (I know there's a good answer 
> to this, but using them together seems like it will be common.)
There is a derived property that will return the width in words based on 
bitWidth and word size.
> 
> - It's also probably worth calling out even more explicitly that bitWidth is 
> a representation property, not a value property. That is, a BigInt with the 
> value "1" could have a bitWidth of 1, 8, or 128.
Noted. Thanks.

> 
> - What does signBitIndex return if self is positive? I ask because it's just 
> not in the doc comment, but thinking about the answer made it obvious that 
> the correct return value for 0 is 0.
The doc comment right now describes the actual behavior from the prototype 
implementation. I plan to document this particular property better after 
cleaning up the prototype.

> 
> - For signed integers, does remainder(dividingBy:) have specified behavior 
> for the sign of the result? See 
> https://en.wikipedia.org/wiki/Modulo_operation 
> .
The behavior should remain the same as it is now (the sign is preserved). I 
guess this just should be explicitly mentioned somewhere. Will do.
> 
> - I do think having Swift.abs(_:) and Integer.absoluteValue is confusing, but 
> I don't know what to do about it.
> 
> 
> - Why are bitwise operations limited to fixed-width integers? I see "The only 
> difference is that because shifting left truncates the high bits of 
> fixed-width integers, it is hard to define what a left shift would mean to an 
> arbitrary-precision integer" further down, but I would just assume it 
> wouldn't truncate (i.e. it would be a pure multiplication by two).
Exactly. It won’t truncate and we considered it to be a sufficient difference 
in behavior to not allow it to be used in the context over all integers.
> 
> - Is there a requirement about left-shifting into the sign bit, for '<<' and 
> for '&<<‘?
The current behavior is to not do anything special about the sign bit. So that 
(64 as Int8) << 1 would result in a -128.

I should probably add a general note somewhere in the proposal that “unless 
specifically mentioned, the behavior will remain consistent with the existing 
implementation”.

> 
> - What is the ArithmeticOverflow type?
It is an enum with 2 cases, just like Optional<()>, but with more specific case 
name. If not for the explicitness, a simple Bool value could have been used.
> 
> - When does the remainder operation overflow? (I just can't remember.)
Discussed in a separate email. The only case where it should trap is ‘division 
by zero’, so this part is subjected to changes.
> 
> - I feel a little weird having "someValue.and(mask)". Maybe bitwiseAnd or 
> bitwise

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

[Jordan Rose via swift-evolution]

> On Jun 23, 2016, at 15:19, Patrick Pijnappel  
> wrote:
> 
> - I remain unconvinced that defining an Arithmetic that includes both exact 
> and floating-point numbers is a good idea. All of the arguments from Swift 1 
> and 2 about why we didn't include this still seem relevant. To phrase it in 
> generic programming terms, what algorithm would be generic over Arithmetic?
> 
> E.g. generic point/size/rect types.

Um. I get that there are useful algorithms generic over floating-point vectors, 
and also useful algorithms generic over integer vectors. I’m still not sure 
what algorithms are generic over floating-point values (of any arity) and 
integers (of any arity).

Jordan

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

[Patrick Pijnappel via swift-evolution]

>
> - I remain unconvinced that defining an Arithmetic that includes both
> exact and floating-point numbers is a good idea. All of the arguments from
> Swift 1 and 2 about why we didn't include this still seem relevant. To
> phrase it in generic programming terms, what algorithm would be generic
> over Arithmetic?
>

E.g. generic point/size/rect types.

> For Integer, does the presence of signBit indicate an expectation that
> signed Integers will have a two's complement representation?
> Yes. That is correct.


So would this require a BigInt implementation to be in two's complement
also? Most BigInt implementations use a separate sign I think, not sure if
that's for performance reasons or merely convenience though.


On Fri, Jun 24, 2016 at 7:40 AM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

> Oh, one more comment: I suggest naming the primary protocol something
> other than "Integer", which IMHO is a little close to "Int" for a beginner.
> "Integral" is a bit too ambiguous, but maybe "IntegerArithmetic" or
> "ArithmeticInteger"? Or to go with the representation thing,
> "BinaryInteger"? (Some of the requirements are at odds with a decimal-based
> implementation.)
>
> Jordan
>
>
> On Jun 23, 2016, at 13:50, Jordan Rose  wrote:
>
> Hey, standard library folks. Glad we're doing this one. :-)
>
> - I remain unconvinced that defining an Arithmetic that includes both
> exact and floating-point numbers is a good idea. All of the arguments from
> Swift 1 and 2 about why we didn't include this still seem relevant. To
> phrase it in generic programming terms, what algorithm would be generic
> over Arithmetic?
>
>
> - What is Integer.init(_:) supposed to do if the
> floating-point value is larger than the maximum representable integer?
> Smaller than the minimum? (As a special case, negative, when the integer
> type is unsigned?) Infinity? NaN?
>
> - Integer.init(_:) currently says "if it is representable". It
> should say something like "trapping if it is not representable".
>
> - I find it odd that Integer.init(clamping:) privileges the bounds of
> fixed-width integers. I was going to suggest it should take a range to
> clamp to that *defaults* to the min and max, but that's not implementable
> for a BigInt.
>
> - nthWord should count "from least-significant to most-significant" rather
> than "from the right".
>
> - As mentioned before, it sounds like Integer requires a two's complement
> representation (if only so the result of nthWord can be interpreted
> correctly). That should probably be in the doc comment for the protocol.
>
> - Why is bitWidth in bits but nthWord in words? (I know there's a good
> answer to this, but using them together seems like it will be common.)
>
> - It's also probably worth calling out *even more explicitly* that
> bitWidth is a *representation* property, not a *value* property. That is,
> a BigInt with the value "1" could have a bitWidth of 1, 8, or 128.
>
> - What does signBitIndex return if self is positive? I ask because it's
> just not in the doc comment, but thinking about the answer made it obvious
> that the correct return value for 0 is 0.
>
> - For signed integers, does remainder(dividingBy:) have specified behavior
> for the sign of the result? See
> https://en.wikipedia.org/wiki/Modulo_operation.
>
> - I do think having Swift.abs(_:) and Integer.absoluteValue is confusing,
> but I don't know what to do about it.
>
>
> - Why are bitwise operations limited to fixed-width integers? I see "The
> only difference is that because shifting left truncates the high bits of
> fixed-width integers, it is hard to define what a left shift would mean to
> an arbitrary-precision integer" further down, but I would just assume it
> wouldn't truncate (i.e. it would be a pure multiplication by two).
>
> - Is there a requirement about left-shifting into the sign bit, for '<<'
> and for '&<<'?
>
> - What is the ArithmeticOverflow type?
>
> - When does the remainder operation overflow? (I just can't remember.)
>
> - I feel a little weird having "someValue.and(mask)". Maybe bitwiseAnd or
> bitwiseAND to be more explicit?
>
> - maskingShiftLeft/Right seem underspecified in their doc comments. Why
> can't the protocol requirement just assume the shift amount has already
> been masked, instead of performing the masking themselves? Is it because we
> won't be able to optimize that away?
>
> I think that's about it. Great work, all!
> Jordan
>
>
>
> ___
> 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] [Review] SE-0103: Make non-escaping closures the default

[Jean-Daniel Dupas via swift-evolution]

-1 for the proposal too

@nonescaping is more restrictive than escaping closure. You can’t pass a non 
escaping closure to a method that expects one, while the reverse is possible.

Nowadays, a method without any annotation defaults to be able to do anything. 
If we switch to non-escaping  as the default, a method without annotation would 
be restricted in what it can do with the closure. That’s why I don’t think this 
is a good move.

for example:

func myfunc(closure: () -> Void) {
stdlibfunction(closure) 
}

Today, whatever the stdlib function annotation is, it will compile. By 
reversing the annotation, that code may compile or not depending the stdlib 
function annotation.

Forcing the newcomer to learn advanced optimization technic to be able to write 
a simple function is very bad IMHO.


> Le 23 juin 2016 à 23:06, Diego Sánchez via swift-evolution 
>  a écrit :
> 
> * What is your evaluation of the proposal?
> 
> -1
> 
> I find myself using 3 types of closures:
>  - Algorithm-like (filter, map etc.). non-escaping
>  - Completion closures: asynchronous operations: network requests, many cocoa 
> APIs, background image processing. escaping
>  - Data/dependency providers: userProvider(forId id: String) -> User. 
> escaping (ok, can be non-escaping sometimes too)
> 
> In the codebases I'm working with, escaping closures predominate clearly; and 
> most of the non-escaping ones refer to usages of the standard library.
> 
> Another point comes when changing things. Consider the following code:
> 
> func doSomething(closure: () -> Void) {
>   self.doSomething2(closure)
> }
> 
> func doSomething2(closure: () -> Void) {
>   self.doSomething3(closure)
> }
> 
> func doSomething3(closure: () -> Void) {
>   closure()
> }
> 
> If non-escaping is the default, and for some reason doSomething3's closure 
> needs to change to escaping, then I would have to change all the callers as 
> escaping.
> 
> To sump up, I see @noescape as something to opt-in for performance reasons 
> (or better static analysis as it was mentioned during the initial discussion) 
> but I don't think it's a good default.
> 
> * Is the problem being addressed significant enough to warrant a change to 
> Swift?
> I don't think there's a problem that needs to be fixed.
> 
> * Does this proposal fit well with the feel and direction of Swift?
> Not really. I think escaping is a safe good default that works for all cases.
> 
> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
> NA
> 
> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> Followed the discussion and read the proposal carefully.
> 
> 
> 2016-06-22 6:03 GMT+01:00 Chris Lattner via swift-evolution 
> mailto:swift-evolution@swift.org>>:
> Hello Swift community,
> 
> The review of "SE-0103: Make non-escaping closures the default" begins now 
> and runs through June 27. The proposal is available here:
> 
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.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.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to 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,
> 
> -Chris Lattner
> 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

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

[Max Moiseev via swift-evolution]

Hi Nicola,

> For these reasons, I think it would make sense to explicitly request that
> the remainder operation never traps, and remove the overflow variants.
It will still trap when you divide by 0. But in that case falling back to the 
same generic overflow logic is not the best idea.
I agree that remainder is special, let me see what I can do about it.

Thanks,
Max


> On Jun 23, 2016, at 2:38 PM, Nicola Salmoria via swift-evolution 
>  wrote:
> 
> Max Moiseev via swift-evolution  writes:
> 
>>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under
> what situations would
>> you have an overflow? I could only come up with something like
> Int.min.dividedWithOverflow(-1).
>> If you look at the prototype here:
>> 
> https://github.com/apple/swift/blob/master/test/Prototypes
> /Integers.swift.gyb#L789
>> there is
>> exactly the check that you’ve mentioned, but for all signed integers.
> Besides, it is very convenient to
>> have all the arithmetic operations be implemented the same way, even if
> there were no real overflows for division.
> 
> I agree with this for the four basic operations, but not for the remainder
> operation.
> 
> By definition, the remainder is always strictly smaller (in absolute value)
> than the divisor, so even if the division itself overflows, the remainder
> must be representable, so technically it never overflow.
> 
> In the only actual case where the division overflow, that is Int.min / -1,
> the remainder is simply 0.
> 
> For these reasons, I think it would make sense to explicitly request that
> the remainder operation never traps, and remove the overflow variants.
> 
> Nicola
> ___
> 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] Stdlib closure argument labels and parameter names

[Erica Sadun via swift-evolution]

> On Jun 23, 2016, at 12:39 AM, David Hart  wrote:
>> -  for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) {
>> +  for test in removeFirstTests.filter(
>> +suchThat: { $0.numberToRemove == 1 }
>> 
>> The difference between `filter` and `forEach` is that `forEach` is 
>> explicitly 
>> procedural while `filter` is functional.  I do not like functional chainable
>> calls being modified to use explicit external labels in this way. 
>> 
>> I'd prefer no label here.
> 
> Quick aside. Eric, if you prefer no label here, why did you not also prefer 
> no labels for contains and elementsEqual? They also have very functional. But 
> if we must have a label, I’d vote for `where`.

contains and elementsEqual both return Booleans which are almost never chained.

-- E

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

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

[Erica Sadun via swift-evolution]

> On Jun 22, 2016, at 1:32 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Wed Jun 22 2016, Erica Sadun  wrote:
> 
>>> On Jun 22, 2016, at 11:51 AM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> on Wed Jun 22 2016, Erica Sadun  wrote:
 
 No, I'd do edits on a gist page not in-place
>>> 
>>> Then feel free, of course!  It's your choice, y'know.  I wouldn't want
>>> to ask you to propose something you don't believe in...
>>> 
>> 
>> I believe the current approach needs improving. I am fine with both
>> approaches.  You've more or less convinced me on a very good reason
>> why a less perfect solution is a better approach.
>> 
>> I just want to know if it would help going into the core team review
>> to have that rationale written up and formal in advance. 
> 
> I think it would.  It would *really* help if someone would prepare a
> patch that uses both APIs so we could see how the resulting code looks
> in practice. :-)
> 
> -- 
> Dave

Here you go: https://gist.github.com/erica/57a64163870486468180b8bab8a6294e 


-- E

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

Re: [swift-evolution] Prohibit invisible characters in identifier names

[João Pinheiro via swift-evolution]

This was exactly the motivation for the proposal and a similar example was 
given on the first email of the thread.

Try this:

func test() { print("A") }
func t​est() { print("B") }
func te​st() { print("C") }

let abc = 1
let a​bc = 2
let ab​c = 3

test()
t​est()
te​st()

print(abc)
print(a​bc)
print(ab​c)

Sincerely,
João Pinheiro


> On 23 Jun 2016, at 22:59, Josh Wisenbaker via swift-evolution 
>  wrote:
> 
> 
>> On Jun 23, 2016, at 4:45 PM, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Let me correct myself: what I think Josh's example is should be corrected 
>> whether we prohibit or ignore. However, since no one can see the invisible 
>> characters he used, I can't say for sure.
>> 
>> If he found a clever way to reorder or change spacing between letters (e.g. 
>> superimpose two characters so that "var11" looks like "var1"), then the 
>> problem can only be fixed by prohibition.
> 
> I asked my colleague who played the prank on me and got the details:
> 
> "Lines 4 and 5 declare variables with embedded Unicode Zero Width Spaces 
> (U+200B) in their names. Line 4 is actually  “var\U+200B1”, not “var1”. Isn’t 
> it nice of Swift to be this flexible 😊”
> 
> Josh
> 
> 
> Josh Wisenbaker
> macsh...@mac.com 
> 
> 
> 
> ___
> 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] Prohibit invisible characters in identifier names

[João Pinheiro via swift-evolution]

Indeed, the case shown in Josh's example was the motivation for this thread and 
will be solved by the proposal.

The current discussion has been around whether it should be solved by ignoring 
invisible characters or prohibiting them and explicitly highlighting them as an 
error. I originally proposed prohibiting them and was convinced into thinking 
that ignoring them would suffice. Upon further reading of the unicode 
normalisation and security documents, I agree that prohibiting them outside of 
the situations described in UAX #31 is the best and safest choice.

Sincerely,
João Pinheiro


> On 23 Jun 2016, at 21:45, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Let me correct myself: what I think Josh's example is should be corrected 
> whether we prohibit or ignore. However, since no one can see the invisible 
> characters he used, I can't say for sure.
> 
> If he found a clever way to reorder or change spacing between letters (e.g. 
> superimpose two characters so that "var11" looks like "var1"), then the 
> problem can only be fixed by prohibition.
> On Thu, Jun 23, 2016 at 15:36 James Hillhouse  > wrote:
> Thanks Xiaodi. That’s a relief to know.
> 
> 
>> On Jun 23, 2016, at 3:32 PM, Xiaodi Wu > > wrote:
>> 
>> FWIW, Josh's example would be fixed whether we prohibit or ignore invisible 
>> characters, but there are other potential strings for which prohibition 
>> would be more secure.
>> 
>> On Thu, Jun 23, 2016 at 15:27 James Hillhouse > > wrote:
>> +1 on this. Josh Wisenbaker’s example says enough. Yikes!
>> 
>>> On Jun 23, 2016, at 3:18 PM, David Sweeris via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> +1
>>> I didn't even know there were any invisible characters until this thread 
>>> came up.
>>> 
>>> - Dave Sweeris
>>> 
>>> On Jun 23, 2016, at 15:13, Xiaodi Wu via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro >>> > wrote:
 
 > On 23 Jun 2016, at 20:43, Xiaodi Wu >>> > > wrote:
 > That's cool, although my preferred solution would be more closely 
 > aligned with UAX #31: overtly disallow the glyphs in Table 4 (instead of 
 > ignoring them) except in the specific scenarios for ZWJ and ZWNJ 
 > identified in UAX #31, then afterwards internally represent the 
 > identifier as its NFC-normalized string.
 
 Explicitly disallowing them was my initial idea, but I think it would end 
 up being a confusing error for users to encounter. Ignoring the invisible 
 characters and leaving it up to a linter to remove them is less likely to 
 cause confusion for users.
 
 I'll be sure to describe the alternative of explicitly prohibiting them in 
 the proposal though.
 
 I would strongly urge you to propose explicitly prohibiting them just as 
 UAX #31 recommends. Their reasoning is that these characters, which 
 include those that reverse text direction or control joining, can cause 
 one identifier to be maliciously changed to look like another. If you 
 ignore these characters instead of prohibiting them, an identifier that 
 visually appears as one string could in fact be a different one to the 
 compiler.
 
 Moreover, a compiler error can be made helpful by saying that the 
 offending character is potentially invisible and it can come with a fix-it 
 to remove the offending character. I don't think that would confuse the 
 user at all. It would be more confusing if invisible characters that 
 caused one thing to look identical to another were silently permitted.
 
 
 Sincerely,
 João Pinheiro
 
 ___
 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
> 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] Prohibit invisible characters in identifier names

[Josh Wisenbaker via swift-evolution]

> On Jun 23, 2016, at 4:45 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Let me correct myself: what I think Josh's example is should be corrected 
> whether we prohibit or ignore. However, since no one can see the invisible 
> characters he used, I can't say for sure.
> 
> If he found a clever way to reorder or change spacing between letters (e.g. 
> superimpose two characters so that "var11" looks like "var1"), then the 
> problem can only be fixed by prohibition.

I asked my colleague who played the prank on me and got the details:

"Lines 4 and 5 declare variables with embedded Unicode Zero Width Spaces 
(U+200B) in their names. Line 4 is actually  “var\U+200B1”, not “var1”. Isn’t 
it nice of Swift to be this flexible 😊”

Josh


Josh Wisenbaker
macsh...@mac.com





smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Stdlib closure argument labels and parameter names

[Anton Zhilin via swift-evolution]

Dave Abrahams via swift-evolution  writes:

> A couple of weeks ago we started to notice that we had some poorly-
named
> closure parameters and argument labels in the standard library, so we
> did a complete audit of the standard library's APIs and came up with a
> preliminary proposal for changes, which we applied in a branch and you
> can review in https://github.com/apple/swift/pull/2981.  Let's please
> carry on further discussion here rather than in the pull request, 
though.

I don't like that more clutter is added to the call site. We can surely 
find shorter and more descriptive names. Remember that most people 
already know what filter, map and reduce means, we don't need to explain 
them.

My suggestions:

filter(where:)
map(over:)
reduce(applying:)
sort(by:)
forEach(do:)

Remember that these functions came from functional languages, where 
function names tend to be brief, and it is considered one of their 
advantages.

Data flow is an area where code becomes the less understandable when 
more visual clutter is added. In my opinion,

array.filter(isEven).map(square).reduce(sum)

reads better than

array.filter(suchThatTrue: isEven).map(applyingTransformation: 
square).reduce(accumulatingResultBy: sum)

What do you think?

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

[Jordan Rose via swift-evolution]

Oh, one more comment: I suggest naming the primary protocol something other 
than "Integer", which IMHO is a little close to "Int" for a beginner. 
"Integral" is a bit too ambiguous, but maybe "IntegerArithmetic" or 
"ArithmeticInteger"? Or to go with the representation thing, "BinaryInteger"? 
(Some of the requirements are at odds with a decimal-based implementation.)

Jordan


> On Jun 23, 2016, at 13:50, Jordan Rose  wrote:
> 
> Hey, standard library folks. Glad we're doing this one. :-)
> 
> - I remain unconvinced that defining an Arithmetic that includes both exact 
> and floating-point numbers is a good idea. All of the arguments from Swift 1 
> and 2 about why we didn't include this still seem relevant. To phrase it in 
> generic programming terms, what algorithm would be generic over Arithmetic?
> 
> 
> - What is Integer.init(_:) supposed to do if the 
> floating-point value is larger than the maximum representable integer? 
> Smaller than the minimum? (As a special case, negative, when the integer type 
> is unsigned?) Infinity? NaN?
> 
> - Integer.init(_:) currently says "if it is representable". It 
> should say something like "trapping if it is not representable".
> 
> - I find it odd that Integer.init(clamping:) privileges the bounds of 
> fixed-width integers. I was going to suggest it should take a range to clamp 
> to that defaults to the min and max, but that's not implementable for a 
> BigInt.
> 
> - nthWord should count "from least-significant to most-significant" rather 
> than "from the right".
> 
> - As mentioned before, it sounds like Integer requires a two's complement 
> representation (if only so the result of nthWord can be interpreted 
> correctly). That should probably be in the doc comment for the protocol.
> 
> - Why is bitWidth in bits but nthWord in words? (I know there's a good answer 
> to this, but using them together seems like it will be common.)
> 
> - It's also probably worth calling out even more explicitly that bitWidth is 
> a representation property, not a value property. That is, a BigInt with the 
> value "1" could have a bitWidth of 1, 8, or 128.
> 
> - What does signBitIndex return if self is positive? I ask because it's just 
> not in the doc comment, but thinking about the answer made it obvious that 
> the correct return value for 0 is 0.
> 
> - For signed integers, does remainder(dividingBy:) have specified behavior 
> for the sign of the result? See 
> https://en.wikipedia.org/wiki/Modulo_operation 
> .
> 
> - I do think having Swift.abs(_:) and Integer.absoluteValue is confusing, but 
> I don't know what to do about it.
> 
> 
> - Why are bitwise operations limited to fixed-width integers? I see "The only 
> difference is that because shifting left truncates the high bits of 
> fixed-width integers, it is hard to define what a left shift would mean to an 
> arbitrary-precision integer" further down, but I would just assume it 
> wouldn't truncate (i.e. it would be a pure multiplication by two).
> 
> - Is there a requirement about left-shifting into the sign bit, for '<<' and 
> for '&<<'?
> 
> - What is the ArithmeticOverflow type?
> 
> - When does the remainder operation overflow? (I just can't remember.)
> 
> - I feel a little weird having "someValue.and(mask)". Maybe bitwiseAnd or 
> bitwiseAND to be more explicit?
> 
> - maskingShiftLeft/Right seem underspecified in their doc comments. Why can't 
> the protocol requirement just assume the shift amount has already been 
> masked, instead of performing the masking themselves? Is it because we won't 
> be able to optimize that away?
> 
> I think that's about it. Great work, all!
> Jordan

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

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

[Nicola Salmoria via swift-evolution]

Max Moiseev via swift-evolution  writes:

> > For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under
what situations would
> you have an overflow? I could only come up with something like
Int.min.dividedWithOverflow(-1).
> If you look at the prototype here:
>
https://github.com/apple/swift/blob/master/test/Prototypes
/Integers.swift.gyb#L789
> there is
> exactly the check that you’ve mentioned, but for all signed integers.
Besides, it is very convenient to
> have all the arithmetic operations be implemented the same way, even if
there were no real overflows for division.

I agree with this for the four basic operations, but not for the remainder
operation.

By definition, the remainder is always strictly smaller (in absolute value)
than the divisor, so even if the division itself overflows, the remainder
must be representable, so technically it never overflow.

In the only actual case where the division overflow, that is Int.min / -1,
the remainder is simply 0.

For these reasons, I think it would make sense to explicitly request that
the remainder operation never traps, and remove the overflow variants.

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

[swift-evolution] [Proposal] Remove Boolean

[Anton Zhilin via swift-evolution]

Following goals of Swift 3, I've prepaired a minimalistic proposal to 
remove Boolean protocol.

https://github.com/Anton3/swift-evolution/blob/remove-
boolean/proposals/-remove-boolean.md

## Introduction

Remove `Boolean` protocol. Only Bool will be able to be used in logical 
contexts:

let x: ObjCBool = true
if x {  // will become an error!
  ...
}

## Motivation

"Boolean" isn't pulling its weight:
- It only abstracts over Bool and ObjCBool.
- It only enables a few operations on ObjCBool, which are not very 
important.
- ObjCBool is a bridging problem, and we don't handle bridging by 
introducing common protocols (e.g. in the case of String vs NSString, we 
don't introduce a common "Stringable" protocol.

Further, it complicates the model:
- People are confused by it and the similar but very different Bool 
type.
- Bool is a simple enough concept to not need a family of protocols.

## Impact on existing code

Change is backwards incompatible, but automatic migration is possible:

- In places where Boolean (but not Bool) was in logical contexts, 
migrator can add `.boolValue`
- Migrator can remove conformances to Boolean

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
 ]

I am already on record as being against this proposal:

> Just because it can be modelled as a type doesn’t mean it’s the best way to 
> represent the concept. It feels like uniformity for uniformity’s sake.
> 
> func fatalError() -> NoReturn
> 
> @noreturn func fatalError()
> 
> The first one probably isn't too hard to explain to a learner. The second one 
> probably doesn’t need an explanation.

(http://thread.gmane.org/gmane.comp.lang.swift.evolution/19958/)

A few more thoughts: I don't think uninhabited types actually come up very 
often (though non-returning functions are also pretty rare). I'm not against 
supporting composition for actual uninhabited types, but I don't think 
composition of NoReturn/Never is particularly interesting. I don't find 
throws compelling enough to add language support for it, but maybe I 
just can't think of a case where you want to be generic over error types.

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

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Slava Pestov via swift-evolution]

> On Jun 23, 2016, at 2:08 PM, Andrew Trick  wrote:
> 
>> 
>> On Jun 23, 2016, at 2:06 PM, Slava Pestov > > wrote:
>> 
>> 
>>> On Jun 23, 2016, at 2:02 PM, Andrew Trick >> > wrote:
>>> 
 
 On Jun 23, 2016, at 1:48 PM, Slava Pestov >>> > wrote:
 
 
> On Jun 23, 2016, at 1:46 PM, Andrew Trick  > wrote:
> 
> 
>> On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> The proposal is to change the type of self to always be Self, which can 
>> be thought of as a special generic type parameter bound to the dynamic 
>> type of the instance.
> 
> We’re currently specializing functions that take `self` as an argument. I 
> don’t think that will be possible after your proposed change.
> 
> - Andy
 
 I’m not sure what that means. Do you currently punt on certain 
 optimizations if a method returns ‘Self’?
 
 It should be possible to keep the reified type information around, by 
 passing in a metatype or something for example. Can you give a concrete 
 code snippet demonstrating the optimization and how this change would 
 inhibit it?
>>> 
>>> We bail out of generic specialization, inlining, and function signature 
>>> specialization when a type substitution contains dynamic self. 
>>> (hasDynamicSelfTypes). So, yes we currently almost entirely punt on 
>>> optimization for methods that return Self.
>> 
>> I see. That makes sense.
>> 
>> I think the problem is that if we specialize a top-level function with a 
>> substitution involving Self, we have no way to recover what the ‘Self’ type 
>> actually is in IRGen. However I think it could be made to work by passing in 
>> a metatype for Self, and somehow ensuring we don’t mix up Self from two 
>> different contexts...
>> 
>> This is certainly a trickier change than I first imagined, but it would be 
>> nice to figure out how to solve this in a principled way so that we can get 
>> these optimizations to be more generally applicable. It seems even more 
>> surprising, now, if changing the return type of a method inhibits 
>> optimizations in a non-obvious way, especially ones that can have a drastic 
>> effect on performance.
>> 
>> I think next week I’ll try implementing this proposal behind a staging flag, 
>> and play around with the optimizer to see how hard it would be plumb through 
>> the relevant type information.
>> 
>> Slava
> 
> Perfect. I didn’t mean to discourage you, just warn you that some 
> benchmarking and optimizer work is also needed.
> 

No worries :) Dynamic ‘Self’ is one of the dark corners of Swift I don’t fully 
understand — so the proposal is as much about cleaning it up as clarifying my 
own understanding of the issues.



> -Andy
> 
>> 
>>> 
>>> I don’t have an interesting case to point out. You can look into any 
>>> trivial example:
>>> 
>>> func foo(_: T) {}
>>> 
>>> func method() {
>>>   foo(self)
>>> }
>>> 
>>> -Andy

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

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

[Anton Zhilin via swift-evolution]

One practical implication of treating Sequence as infinite is in lazy 
filter. If you pass Sequence, but not Collection, to lazy filter, it will 
guarantee to iterate it only once. If it's a collection, it will feel free 
to iterate it twice.

So one benefit of single-pass sequences is assumptions about behaviour of 
an API: if it can work with sequences, then it will only iterate them 
once.

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

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Anton Zhilin via swift-evolution]

Definitely +1. This is an "accept or reject" kind of proposal with no room 
for discussion, so go ahead and submit it!

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

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Slava Pestov via swift-evolution]

> On Jun 23, 2016, at 2:02 PM, Andrew Trick  wrote:
> 
>> 
>> On Jun 23, 2016, at 1:48 PM, Slava Pestov > > wrote:
>> 
>> 
>>> On Jun 23, 2016, at 1:46 PM, Andrew Trick >> > wrote:
>>> 
>>> 
 On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 The proposal is to change the type of self to always be Self, which can be 
 thought of as a special generic type parameter bound to the dynamic type 
 of the instance.
>>> 
>>> We’re currently specializing functions that take `self` as an argument. I 
>>> don’t think that will be possible after your proposed change.
>>> 
>>> - Andy
>> 
>> I’m not sure what that means. Do you currently punt on certain optimizations 
>> if a method returns ‘Self’?
>> 
>> It should be possible to keep the reified type information around, by 
>> passing in a metatype or something for example. Can you give a concrete code 
>> snippet demonstrating the optimization and how this change would inhibit it?
> 
> We bail out of generic specialization, inlining, and function signature 
> specialization when a type substitution contains dynamic self. 
> (hasDynamicSelfTypes). So, yes we currently almost entirely punt on 
> optimization for methods that return Self.

I see. That makes sense.

I think the problem is that if we specialize a top-level function with a 
substitution involving Self, we have no way to recover what the ‘Self’ type 
actually is in IRGen. However I think it could be made to work by passing in a 
metatype for Self, and somehow ensuring we don’t mix up Self from two different 
contexts...

This is certainly a trickier change than I first imagined, but it would be nice 
to figure out how to solve this in a principled way so that we can get these 
optimizations to be more generally applicable. It seems even more surprising, 
now, if changing the return type of a method inhibits optimizations in a 
non-obvious way, especially ones that can have a drastic effect on performance.

I think next week I’ll try implementing this proposal behind a staging flag, 
and play around with the optimizer to see how hard it would be plumb through 
the relevant type information.

Slava

> 
> I don’t have an interesting case to point out. You can look into any trivial 
> example:
> 
> func foo(_: T) {}
> 
> func method() {
>   foo(self)
> }
> 
> -Andy

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

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Andrew Trick via swift-evolution]

> On Jun 23, 2016, at 2:06 PM, Slava Pestov  wrote:
> 
> 
>> On Jun 23, 2016, at 2:02 PM, Andrew Trick > > wrote:
>> 
>>> 
>>> On Jun 23, 2016, at 1:48 PM, Slava Pestov >> > wrote:
>>> 
>>> 
 On Jun 23, 2016, at 1:46 PM, Andrew Trick >>> > wrote:
 
 
> On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> The proposal is to change the type of self to always be Self, which can 
> be thought of as a special generic type parameter bound to the dynamic 
> type of the instance.
 
 We’re currently specializing functions that take `self` as an argument. I 
 don’t think that will be possible after your proposed change.
 
 - Andy
>>> 
>>> I’m not sure what that means. Do you currently punt on certain 
>>> optimizations if a method returns ‘Self’?
>>> 
>>> It should be possible to keep the reified type information around, by 
>>> passing in a metatype or something for example. Can you give a concrete 
>>> code snippet demonstrating the optimization and how this change would 
>>> inhibit it?
>> 
>> We bail out of generic specialization, inlining, and function signature 
>> specialization when a type substitution contains dynamic self. 
>> (hasDynamicSelfTypes). So, yes we currently almost entirely punt on 
>> optimization for methods that return Self.
> 
> I see. That makes sense.
> 
> I think the problem is that if we specialize a top-level function with a 
> substitution involving Self, we have no way to recover what the ‘Self’ type 
> actually is in IRGen. However I think it could be made to work by passing in 
> a metatype for Self, and somehow ensuring we don’t mix up Self from two 
> different contexts...
> 
> This is certainly a trickier change than I first imagined, but it would be 
> nice to figure out how to solve this in a principled way so that we can get 
> these optimizations to be more generally applicable. It seems even more 
> surprising, now, if changing the return type of a method inhibits 
> optimizations in a non-obvious way, especially ones that can have a drastic 
> effect on performance.
> 
> I think next week I’ll try implementing this proposal behind a staging flag, 
> and play around with the optimizer to see how hard it would be plumb through 
> the relevant type information.
> 
> Slava

Perfect. I didn’t mean to discourage you, just warn you that some benchmarking 
and optimizer work is also needed.

-Andy

> 
>> 
>> I don’t have an interesting case to point out. You can look into any trivial 
>> example:
>> 
>> func foo(_: T) {}
>> 
>> func method() {
>>   foo(self)
>> }
>> 
>> -Andy
> 

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

Re: [swift-evolution] [Review] SE-0103: Make non-escaping closures the default

[Diego Sánchez via swift-evolution]

** What is your evaluation of the proposal?*

-1

I find myself using 3 types of closures:
 - Algorithm-like (filter, map etc.). non-escaping
 - Completion closures: asynchronous operations: network requests, many
cocoa APIs, background image processing. escaping
 - Data/dependency providers: userProvider(forId id: String) -> User.
escaping (ok, can be non-escaping sometimes too)

In the codebases I'm working with, escaping closures predominate clearly;
and most of the non-escaping ones refer to usages of the standard library.

Another point comes when changing things. Consider the following code:

func doSomething(closure: () -> Void) {
self.doSomething2(closure)
}

func doSomething2(closure: () -> Void) {
self.doSomething3(closure)
}

func doSomething3(closure: () -> Void) {
closure()
}

If non-escaping is the default, and for some reason doSomething3's closure
needs to change to escaping, then I would have to change all the callers as
escaping.

To sump up, I see @noescape as something to opt-in for performance reasons
(or better static analysis as it was mentioned during the initial
discussion) but I don't think it's a good default.

** Is the problem being addressed significant enough to warrant a change to
Swift?*
I don't think there's a problem that needs to be fixed.

** Does this proposal fit well with the feel and direction of Swift?*
Not really. I think escaping is a safe good default that works for all
cases.

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

** How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?*
Followed the discussion and read the proposal carefully.


2016-06-22 6:03 GMT+01:00 Chris Lattner via swift-evolution <
swift-evolution@swift.org>:

> Hello Swift community,
>
> The review of "SE-0103: Make non-escaping closures the default" begins now
> and runs through June 27. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.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.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to 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,
>
> -Chris Lattner
> 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] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Jordan Rose via swift-evolution]

> On Jun 21, 2016, at 11:01, Ben Rimmington via swift-evolution 
>  wrote:
> 
> * [LibraryEvolution.rst] @noreturn is a versioned attribute, so how will this 
> proposal affect that design?
> 
>  >

Thanks for bringing this up. I think we'd just lose the ability to add 
noreturn-like behavior retroactively, which seems like not such a big loss.

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

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Andrew Trick via swift-evolution]

> On Jun 23, 2016, at 1:48 PM, Slava Pestov  wrote:
> 
> 
>> On Jun 23, 2016, at 1:46 PM, Andrew Trick > > wrote:
>> 
>> 
>>> On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> The proposal is to change the type of self to always be Self, which can be 
>>> thought of as a special generic type parameter bound to the dynamic type of 
>>> the instance.
>> 
>> We’re currently specializing functions that take `self` as an argument. I 
>> don’t think that will be possible after your proposed change.
>> 
>> - Andy
> 
> I’m not sure what that means. Do you currently punt on certain optimizations 
> if a method returns ‘Self’?
> 
> It should be possible to keep the reified type information around, by passing 
> in a metatype or something for example. Can you give a concrete code snippet 
> demonstrating the optimization and how this change would inhibit it?

We bail out of generic specialization, inlining, and function signature 
specialization when a type substitution contains dynamic self. 
(hasDynamicSelfTypes). So, yes we currently almost entirely punt on 
optimization for methods that return Self.

I don’t have an interesting case to point out. You can look into any trivial 
example:

func foo(_: T) {}

func method() {
  foo(self)
}

-Andy

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

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

[Xiaodi Wu via swift-evolution]

On Thu, Jun 23, 2016 at 1:56 PM, Max Moiseev  wrote:

> Hi Xiaodi,
>
> Q2: I do not understand the comment explaining signBitIndex. I thought I
> understood what it does from the name, but the comment says it's not the
> right name. So what is signBitIndex?
>
> The name is good but the way it is implemented in the prototype currently
> is NOT what the name suggests. This is the point of the comment. I plan to
> revisit the prototype and either make it behave the way it’s called, or
> find a better name for what it currently does.
>
> Ask: You've got bitWidth and nthWord. Any way you could expose
> __builtin_popcount()? Pretty please?
>
> I don’t mind adding it to the concrete types, similar to
> `countLeadingZeros` (see
> https://github.com/apple/swift/blob/master/test/Prototypes/Integers.swift.gyb#L855).
> Do you think it should be a protocol requirement instead?
>

You're right, probably best belongs on concrete types.


>
>
> Max
>
>
> On Jun 22, 2016, at 6:13 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Wed, Jun 22, 2016 at 7:52 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hello Swift community,
>>
>> The review of "SE-0104: Protocol-oriented integers" begins now and runs
>> through June 27. The proposal is available here:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.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.
>>
>> What goes into a review?
>>
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and contribute to 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?
>>
>
> This is excellent, and a huge improvement. Two questions and one ask:
>
> Q1: With the adoption of this proposal, will FloatingPoint conform to
> Arithmetic?
> Q2: I do not understand the comment explaining signBitIndex. I thought I
> understood what it does from the name, but the comment says it's not the
> right name. So what is signBitIndex?
> Ask: You've got bitWidth and nthWord. Any way you could expose
> __builtin_popcount()? Pretty please?
>
>
>> * Is the problem being addressed significant enough to warrant a
>> change to Swift?
>>
>
> Yes, the current tangle of protocols is not exactly fun to work with for
> generics.
>
>
>> * Does this proposal fit well with the feel and direction of
>> Swift?
>>
>
> Yes.
>
>
>> * If you have used other languages or libraries with a similar
>> feature, how do you feel that this proposal compares to those?
>>
>
> Not applicable, I think.
>
>
>> * How much effort did you put into your review? A glance, a
>> quick reading, or an in-depth study?
>>
>
> Read the proposal, worked with the existing protocols, thought carefully
> about numbers in the context of the FloatingPoint discussion.
>
>
>> More information about the Swift evolution process is available at
>>
>> https://github.com/apple/swift-evolution/blob/master/process.md
>>
>> Thank you,
>>
>> -Chris Lattner
>> 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
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Slava Pestov via swift-evolution]

> On Jun 23, 2016, at 1:48 PM, Sean Heber  wrote:
> 
> So the only real downside of this is that if you don’t refer/use all of the 
> generic types in this sort of situation, then it couldn’t figure it out? So 
> the following wouldn’t be a problem even if rule 1 was eliminated because 
> this actually ties other.value to self’s value and implies that other must be 
> GenericBox?
> 
> struct GenericBox {
>let value: Contents
> 
>func test(other: GenericBox) -> Bool {
>return value === other.value
>}
> }
> 
> I might be totally not understanding, though. :P

This would *not* work with my proposed change. Even though we could 
theoretically infer that the parameter must be a GenericBox to make 
the === type check, in practice Swift’s type checker operates at the expression 
level.

Global type inference is not something we’re considering, because of the 
compile-time cost, increased difficulty in producing localized diagnostics, and 
the loss of too much explicit type information.

> 
> l8r
> Sean
> 
> 
>> On Jun 23, 2016, at 3:30 PM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu  wrote:
>>> 
>>> When you mention the difficulty of an alternative, is that to say that it's 
>>> not feasible for the GenericBox in the last example to be resolved as 
>>> GenericBox? From an end-user point of view, that seems to be the most 
>>> sensible behavior.
>> 
>> With my proposed change, GenericBox would be resolved as GenericBox in 
>> the last example. Right now it fails to type check.
>> 
>> Here is an example that works right now, but would not work with my proposed 
>> change:
>> 
>> struct GenericBox {
>>  // Currently Swift resolves this as ‘GenericBox’
>>  // With the new rule, we cannot infer the parameter, because there’s no 
>> expression to infer it from
>>  func combine(other: GenericBox) {
>>  …
>>  }
>> }
>> 
>> Basically the meaning of ‘GenericBox’ right now depends on whether it 
>> appears inside its own definition or extension thereof, or not. The behavior 
>> when it appears elsewhere is more general — we infer the parameters from the 
>> surrounding expression, instead of assuming they’re equal to the context 
>> parameters.
>> 
>> This is a subtle change — definitely let me know if I’m not explaining it 
>> well.
>> 
>> Slava
>> 
>>> On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution 
>>>  wrote:
>>> Simpler interpretation of a reference to a generic type with no arguments
>>> 
>>> • Proposal: SE-
>>> • Author: Slava Pestov
>>> • Status: Awaiting review
>>> • Review manager: TBD
>>> Introduction
>>> 
>>> This proposal cleans up the semantics of a reference to a generic type when 
>>> no generic arguments are applied.
>>> 
>>> Swift-evolution thread: Discussion thread topic for that proposal
>>> 
>>> Motivation
>>> 
>>> Right now, we allow a generic type to be referenced with no generic 
>>> arguments applied in a handful of special cases. The two primary rules here 
>>> are the following:
>>> 
>>> • If the scope from which the reference is made is nested inside the 
>>> definition of the type or an extension thereof, omitting generic arguments 
>>> just means to implicitly apply the arguments from context.
>>> 
>>> For example,
>>> 
>>> struct GenericBox
>>> {
>>> 
>>> let
>>> contents: Contents
>>> 
>>> 
>>> // Equivalent to: func clone() -> GenericBox
>>> 
>>> 
>>> func clone() ->
>>> GenericBox {
>>> 
>>> return
>>> GenericBox(contents: contents)
>>>  }
>>> }
>>> 
>>> 
>>> extension
>>> GenericBox {
>>> 
>>> func print
>>> () {
>>> 
>>> // Equivalent to: let cloned: GenericBox
>>> 
>>> 
>>> let cloned: GenericBox =
>>> clone()
>>> 
>>> print(cloned.
>>> contents)
>>>  }
>>> }
>>> 
>>> • If the type is referenced from an unrelated scope, we attempt to 
>>> infer the generic parameters.
>>> 
>>> For example,
>>> 
>>> func makeABox() -> GenericBox>>> {
>>> 
>>> // Equivalent to: GenericBox(contents: 123)
>>> 
>>> 
>>> return GenericBox(contents: 123
>>> )
>>> }
>>> 
>>> The problem appears when the user expects the second behavior, but instead 
>>> encounters the first. For example, the following does not type check:
>>> 
>>> extension
>>> GenericBox {
>>> 
>>> 
>>> func transform(f: Contents -> T) ->
>>> GenericBox {
>>> 
>>> // We resolve 'GenericBox' as 'GenericBox', rather than
>>> 
>>> 
>>> // inferring the type parameter
>>> 
>>> 
>>> return
>>> GenericBox(contents: f(contents))
>>>  }
>>> }
>>> 
>>> Proposed solution
>>> 
>>> The proposed solution is to remove the first rule altogether. If the 
>>> generic parameters cannot be inferred from context, they must be specified 
>>> explicitly with the usual Type syntax.
>>> 
>>> Detailed design
>>> 
>>> This really just involves removing an existing piece of logic from the type 
>>> resolver code.
>>> 
>>> Impact on existing code
>>> 
>>> This will have a small impact on existing code that uses a pattern similar 

[swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[Denis Nikitenko via swift-evolution]

 * What is your evaluation of the proposal? 

+1.  I think that overall it’s a step in the right direction.

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

A function that never returns is fundamentally different from any other 
function.  Having this property captured in the function type - rather than 
additional meta-programming attributes - makes sense.  It also prevents the 
language users from creating nonsensical function signatures, such as @noreturn 
func test() -> Int (which happily compiles and runs fine in XCode 8).

The NoReturn type has precedence in both computer science theory and modern 
general purpose programming languages.  I suspect a more generally named 
universal bottom type would be more "future-proof", but I have no strong 
opinion on the matter.

While this is a breaking change, it affects a small corner of the language.  I 
see the benefit outweighing the cost.

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

Yes.

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

I am aware of the existence of the bottom type in Scala and Rust, but I haven’t 
worked with them.

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

A quick review, as well as a quick scan through the literature. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0104: Protocol-oriented integers

[Jordan Rose via swift-evolution]

Hey, standard library folks. Glad we're doing this one. :-)

- I remain unconvinced that defining an Arithmetic that includes both exact and 
floating-point numbers is a good idea. All of the arguments from Swift 1 and 2 
about why we didn't include this still seem relevant. To phrase it in generic 
programming terms, what algorithm would be generic over Arithmetic?


- What is Integer.init(_:) supposed to do if the 
floating-point value is larger than the maximum representable integer? Smaller 
than the minimum? (As a special case, negative, when the integer type is 
unsigned?) Infinity? NaN?

- Integer.init(_:) currently says "if it is representable". It 
should say something like "trapping if it is not representable".

- I find it odd that Integer.init(clamping:) privileges the bounds of 
fixed-width integers. I was going to suggest it should take a range to clamp to 
that defaults to the min and max, but that's not implementable for a BigInt.

- nthWord should count "from least-significant to most-significant" rather than 
"from the right".

- As mentioned before, it sounds like Integer requires a two's complement 
representation (if only so the result of nthWord can be interpreted correctly). 
That should probably be in the doc comment for the protocol.

- Why is bitWidth in bits but nthWord in words? (I know there's a good answer 
to this, but using them together seems like it will be common.)

- It's also probably worth calling out even more explicitly that bitWidth is a 
representation property, not a value property. That is, a BigInt with the value 
"1" could have a bitWidth of 1, 8, or 128.

- What does signBitIndex return if self is positive? I ask because it's just 
not in the doc comment, but thinking about the answer made it obvious that the 
correct return value for 0 is 0.

- For signed integers, does remainder(dividingBy:) have specified behavior for 
the sign of the result? See https://en.wikipedia.org/wiki/Modulo_operation.

- I do think having Swift.abs(_:) and Integer.absoluteValue is confusing, but I 
don't know what to do about it.


- Why are bitwise operations limited to fixed-width integers? I see "The only 
difference is that because shifting left truncates the high bits of fixed-width 
integers, it is hard to define what a left shift would mean to an 
arbitrary-precision integer" further down, but I would just assume it wouldn't 
truncate (i.e. it would be a pure multiplication by two).

- Is there a requirement about left-shifting into the sign bit, for '<<' and 
for '&<<'?

- What is the ArithmeticOverflow type?

- When does the remainder operation overflow? (I just can't remember.)

- I feel a little weird having "someValue.and(mask)". Maybe bitwiseAnd or 
bitwiseAND to be more explicit?

- maskingShiftLeft/Right seem underspecified in their doc comments. Why can't 
the protocol requirement just assume the shift amount has already been masked, 
instead of performing the masking themselves? Is it because we won't be able to 
optimize that away?

I think that's about it. Great work, all!
Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Sean Heber via swift-evolution]

So the only real downside of this is that if you don’t refer/use all of the 
generic types in this sort of situation, then it couldn’t figure it out? So the 
following wouldn’t be a problem even if rule 1 was eliminated because this 
actually ties other.value to self’s value and implies that other must be 
GenericBox?

struct GenericBox {
let value: Contents

func test(other: GenericBox) -> Bool {
return value === other.value
}
}

I might be totally not understanding, though. :P

l8r
Sean


> On Jun 23, 2016, at 3:30 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
>> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu  wrote:
>> 
>> When you mention the difficulty of an alternative, is that to say that it's 
>> not feasible for the GenericBox in the last example to be resolved as 
>> GenericBox? From an end-user point of view, that seems to be the most 
>> sensible behavior.
> 
> With my proposed change, GenericBox would be resolved as GenericBox in the 
> last example. Right now it fails to type check.
> 
> Here is an example that works right now, but would not work with my proposed 
> change:
> 
> struct GenericBox {
>   // Currently Swift resolves this as ‘GenericBox’
>   // With the new rule, we cannot infer the parameter, because there’s no 
> expression to infer it from
>   func combine(other: GenericBox) {
>   …
>   }
> }
> 
> Basically the meaning of ‘GenericBox’ right now depends on whether it appears 
> inside its own definition or extension thereof, or not. The behavior when it 
> appears elsewhere is more general — we infer the parameters from the 
> surrounding expression, instead of assuming they’re equal to the context 
> parameters.
> 
> This is a subtle change — definitely let me know if I’m not explaining it 
> well.
> 
> Slava
> 
>> On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution 
>>  wrote:
>> Simpler interpretation of a reference to a generic type with no arguments
>> 
>>  • Proposal: SE-
>>  • Author: Slava Pestov
>>  • Status: Awaiting review
>>  • Review manager: TBD
>> Introduction
>> 
>> This proposal cleans up the semantics of a reference to a generic type when 
>> no generic arguments are applied.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> Right now, we allow a generic type to be referenced with no generic 
>> arguments applied in a handful of special cases. The two primary rules here 
>> are the following:
>> 
>>  • If the scope from which the reference is made is nested inside the 
>> definition of the type or an extension thereof, omitting generic arguments 
>> just means to implicitly apply the arguments from context.
>> 
>> For example,
>> 
>> struct GenericBox
>>  {
>>   
>> let
>>  contents: Contents
>> 
>>   
>> // Equivalent to: func clone() -> GenericBox
>> 
>>   
>> func clone() ->
>>  GenericBox {
>> 
>> return
>>  GenericBox(contents: contents)
>>   }
>> }
>> 
>> 
>> extension
>>  GenericBox {
>>   
>> func print
>> () {
>> 
>> // Equivalent to: let cloned: GenericBox
>> 
>> 
>> let cloned: GenericBox =
>>  clone()
>> 
>> print(cloned.
>> contents)
>>   }
>> }
>> 
>>  • If the type is referenced from an unrelated scope, we attempt to 
>> infer the generic parameters.
>> 
>> For example,
>> 
>> func makeABox() -> GenericBox> > {
>>   
>> // Equivalent to: GenericBox(contents: 123)
>> 
>>   
>> return GenericBox(contents: 123
>> )
>> }
>> 
>> The problem appears when the user expects the second behavior, but instead 
>> encounters the first. For example, the following does not type check:
>> 
>> extension
>>  GenericBox {
>> 
>>   
>> func transform(f: Contents -> T) ->
>>  GenericBox {
>> 
>> // We resolve 'GenericBox' as 'GenericBox', rather than
>> 
>> 
>> // inferring the type parameter
>> 
>> 
>> return
>>  GenericBox(contents: f(contents))
>>   }
>> }
>> 
>> Proposed solution
>> 
>> The proposed solution is to remove the first rule altogether. If the generic 
>> parameters cannot be inferred from context, they must be specified 
>> explicitly with the usual Type syntax.
>> 
>> Detailed design
>> 
>> This really just involves removing an existing piece of logic from the type 
>> resolver code.
>> 
>> Impact on existing code
>> 
>> This will have a small impact on existing code that uses a pattern similar 
>> to the above.
>> 
>> Alternatives considered
>> 
>> Status quo
>> 
>> We could keep the current behavior, but one can argue it is not very useful, 
>> and adds a special case where one is not needed.
>> 
>> More complex inference of generic parameters
>> 
>> We could attempt to unify the two rules for resolving a reference to a 
>> generic type with no arguments, however this presents theoretical 
>> difficulties with our constraint solver design. Even if it were easy to 
>> implement, it would increase type checking type by creating new 
>> possibilities to consider, with very little actual

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Slava Pestov via swift-evolution]

> On Jun 23, 2016, at 1:46 PM, Andrew Trick  wrote:
> 
> 
>> On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> The proposal is to change the type of self to always be Self, which can be 
>> thought of as a special generic type parameter bound to the dynamic type of 
>> the instance.
> 
> We’re currently specializing functions that take `self` as an argument. I 
> don’t think that will be possible after your proposed change.
> 
> - Andy

I’m not sure what that means. Do you currently punt on certain optimizations if 
a method returns ‘Self’?

It should be possible to keep the reified type information around, by passing 
in a metatype or something for example. Can you give a concrete code snippet 
demonstrating the optimization and how this change would inhibit it?

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

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Matthew Johnson via swift-evolution]

+1 again.  Thanks for ferreting out these surprising behaviors Slava!

I did not realize the shorthand you propose to remove was possible (is this 
documented anywhere?).  On the other hand, I make use of the inference that 
does not work correctly in the “broken” example all the time.  

This is another one that would have been pretty confusing to me had I run into 
it.  I don’t believe there is any other context where explicit type arguments 
are required in a type context where they should be inferred.  Fixing this is 
really important.

I think a reasonably strong argument can be made to remove the first behavior 
even without this conflict.  I really like Swift’s approach of making type 
information explicit in signatures.  Allowing it to be inferred in an obscure 
corner case violates that principle.  

I also think it is reasonable to require the programmer to state all type 
information explicitly when it isn’t inferred.  This makes the code more clear 
to a reader.  Type information is either stated or not stated, never partially 
stated (requiring the programmer to remember what pieces are inferred as well 
as when partial inference is possible and when it is not possible).

It’s also worth noting that in one of your clone example the whole type could 
be inferred:

let cloned = clone()


> On Jun 23, 2016, at 3:14 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Simpler interpretation of a reference to a generic type with no arguments
> 
> Proposal: SE- 
> 
> Author: Slava Pestov 
> Status: Awaiting review
> Review manager: TBD
>  
> Introduction
> 
> This proposal cleans up the semantics of a reference to a generic type when 
> no generic arguments are applied.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> Right now, we allow a generic type to be referenced with no generic arguments 
> applied in a handful of special cases. The two primary rules here are the 
> following:
> 
> If the scope from which the reference is made is nested inside the definition 
> of the type or an extension thereof, omitting generic arguments just means to 
> implicitly apply the arguments from context.
> 
> For example,
> 
> struct GenericBox {
>   let contents: Contents
> 
>   // Equivalent to: func clone() -> GenericBox
>   func clone() -> GenericBox {
> return GenericBox(contents: contents)
>   }
> }
> 
> extension GenericBox {
>   func print() {
> // Equivalent to: let cloned: GenericBox
> let cloned: GenericBox = clone()
> print(cloned.contents)
>   }
> }
> If the type is referenced from an unrelated scope, we attempt to infer the 
> generic parameters.
> 
> For example,
> 
> func makeABox() -> GenericBox {
>   // Equivalent to: GenericBox(contents: 123)
>   return GenericBox(contents: 123)
> }
> The problem appears when the user expects the second behavior, but instead 
> encounters the first. For example, the following does not type check:
> 
> extension GenericBox {
> 
>   func transform(f: Contents -> T) -> GenericBox {
> // We resolve 'GenericBox' as 'GenericBox', rather than
> // inferring the type parameter
> return GenericBox(contents: f(contents))
>   }
> }
>  
> Proposed
>  solution
> 
> The proposed solution is to remove the first rule altogether. If the generic 
> parameters cannot be inferred from context, they must be specified explicitly 
> with the usual Type syntax.
> 
>  
> Detailed
>  design
> 
> This really just involves removing an existing piece of logic from the type 
> resolver code.
> 
>  
> Impact
>  on existing code
> 
> This will have a small impact on existing code that uses a pattern similar to 
> the above.
> 
>  
> Alternatives
>  considered
> 
>  
> Status
>  quo
> 
> We could keep the current behavior, but one can argue it is not very useful, 
> and adds a special case where one is not needed.
> 
>  
> More
>  complex inference of generic parameters
> 
> We could attempt to unify the two rules for resolving a refer

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Xiaodi Wu via swift-evolution]

Cool--no opposition here!
On Thu, Jun 23, 2016 at 15:43 Slava Pestov  wrote:

> On Jun 23, 2016, at 1:39 PM, Xiaodi Wu  wrote:
>
> Good to know. I absolutely agree that the gains to be had here wouldn't be
> worth a one-off hack.
>
>
> If people are strongly (or even mildly) opposed to removing this rule, we
> can give some thought to a more general solution. I don’t feel very
> strongly about this proposal one way or another, it’s just a bit of ugly
> code in TypeCheckType.cpp that would be nice to remove, and a developer on
> Twitter recently noticed this behavior and found it surprising.
>
> On Thu, Jun 23, 2016 at 15:36 Slava Pestov  wrote:
>
>> On Jun 23, 2016, at 1:34 PM, Xiaodi Wu  wrote:
>>
>> Sorry, it's I who is saying things all wrong. I meant to ask, is it
>> feasible to keep both behaviors but have #2 "win" over #1, instead of
>> getting rid of behavior #1 entirely?
>>
>>
>> I suspect there might be some way, but I think it would have to be some
>> kind of one-off hack, which is not in line with our long-term goal of
>> making the type checker more maintainable and correct ‘by construction’.
>>
>>
>> On Thu, Jun 23, 2016 at 15:30 Slava Pestov  wrote:
>>
>>> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu  wrote:
>>>
>>> When you mention the difficulty of an alternative, is that to say that
>>> it's not feasible for the GenericBox in the last example to be resolved as
>>> GenericBox? From an end-user point of view, that seems to be the most
>>> sensible behavior.
>>>
>>>
>>> With my proposed change, GenericBox would be resolved as GenericBox
>>> in the last example. Right now it fails to type check.
>>>
>>> Here is an example that works right now, but would not work with my
>>> proposed change:
>>>
>>> struct GenericBox {
>>> // Currently Swift resolves this as ‘GenericBox’
>>> // With the new rule, we cannot infer the parameter, because there’s no
>>> expression to infer it from
>>> func combine(other: GenericBox) {
>>> …
>>> }
>>> }
>>>
>>> Basically the meaning of ‘GenericBox’ right now depends on whether it
>>> appears inside its own definition or extension thereof, or not. The
>>> behavior when it appears elsewhere is more general — we infer the
>>> parameters from the surrounding expression, instead of assuming they’re
>>> equal to the context parameters.
>>>
>>> This is a subtle change — definitely let me know if I’m not explaining
>>> it well.
>>>
>>> Slava
>>>
>>> On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Simpler interpretation of a reference to a generic type with no
 arguments

- Proposal: SE-

 
- Author: Slava Pestov 
- Status: Awaiting review
- Review manager: TBD


 
 Introduction

 This proposal cleans up the semantics of a reference to a generic type
 when no generic arguments are applied.

 Swift-evolution thread: Discussion thread topic for that proposal
 

 
 Motivation

 Right now, we allow a generic type to be referenced with no generic
 arguments applied in a handful of special cases. The two primary rules here
 are the following:

-

If the scope from which the reference is made is nested inside the
definition of the type or an extension thereof, omitting generic 
 arguments
just means to implicitly apply the arguments from context.

For example,

 struct GenericBox {
   let contents: Contents

   // Equivalent to: func clone() -> GenericBox
   func clone() -> GenericBox {
 return GenericBox(contents: contents)
   }
 }
 extension GenericBox {
   func print() {
 // Equivalent to: let cloned: GenericBox
 let cloned: GenericBox = clone()
 print(cloned.contents)
   }
 }


-

If the type is referenced from an unrelated scope, we attempt to
infer the generic parameters.

For example,

 func makeABox() -> GenericBox {
   // Equivalent to: GenericBox(contents: 123)
   return GenericBox(contents: 123)
 }

 The problem appears when the user expects the second behavior, but
 instead encounters the first. For example, the following does not type
 check:

 extension GenericBox {

   func transform(f: Contents -> T) -> GenericBox {
 // We resolve 'GenericBox' as 'GenericBox', rather than
 // inferring the type parameter
 return GenericBox(contents: f(contents))
   }

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Andrew Trick via swift-evolution]

> On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> The proposal is to change the type of self to always be Self, which can be 
> thought of as a special generic type parameter bound to the dynamic type of 
> the instance.

We’re currently specializing functions that take `self` as an argument. I don’t 
think that will be possible after your proposed change.

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

Re: [swift-evolution] Prohibit invisible characters in identifier names

[Xiaodi Wu via swift-evolution]

Let me correct myself: what I think Josh's example is should be corrected
whether we prohibit or ignore. However, since no one can see the invisible
characters he used, I can't say for sure.

If he found a clever way to reorder or change spacing between letters (e.g.
superimpose two characters so that "var11" looks like "var1"), then the
problem can only be fixed by prohibition.
On Thu, Jun 23, 2016 at 15:36 James Hillhouse 
wrote:

> Thanks Xiaodi. That’s a relief to know.
>
>
> On Jun 23, 2016, at 3:32 PM, Xiaodi Wu  wrote:
>
> FWIW, Josh's example would be fixed whether we prohibit or ignore
> invisible characters, but there are other potential strings for which
> prohibition would be more secure.
>
> On Thu, Jun 23, 2016 at 15:27 James Hillhouse 
> wrote:
>
>> +1 on this. Josh Wisenbaker’s example says enough. Yikes!
>>
>> On Jun 23, 2016, at 3:18 PM, David Sweeris via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> +1
>> I didn't even know there were any invisible characters until this thread
>> came up.
>>
>> - Dave Sweeris
>>
>> On Jun 23, 2016, at 15:13, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro 
>> wrote:
>>
>>>
>>> > On 23 Jun 2016, at 20:43, Xiaodi Wu  wrote:
>>> > That's cool, although my preferred solution would be more closely
>>> aligned with UAX #31: overtly disallow the glyphs in Table 4 (instead of
>>> ignoring them) except in the specific scenarios for ZWJ and ZWNJ identified
>>> in UAX #31, then afterwards internally represent the identifier as its
>>> NFC-normalized string.
>>>
>>> Explicitly disallowing them was my initial idea, but I think it would
>>> end up being a confusing error for users to encounter. Ignoring the
>>> invisible characters and leaving it up to a linter to remove them is less
>>> likely to cause confusion for users.
>>>
>>> I'll be sure to describe the alternative of explicitly prohibiting them
>>> in the proposal though.
>>>
>>
>> I would strongly urge you to propose explicitly prohibiting them just as
>> UAX #31 recommends. Their reasoning is that these characters, which include
>> those that reverse text direction or control joining, can cause one
>> identifier to be maliciously changed to look like another. If you ignore
>> these characters instead of prohibiting them, an identifier that visually
>> appears as one string could in fact be a different one to the compiler.
>>
>> Moreover, a compiler error can be made helpful by saying that the
>> offending character is potentially invisible and it can come with a fix-it
>> to remove the offending character. I don't think that would confuse the
>> user at all. It would be more confusing if invisible characters that caused
>> one thing to look identical to another were silently permitted.
>>
>>
>>> Sincerely,
>>> João Pinheiro
>>
>>
>> ___
>> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Slava Pestov via swift-evolution]

> On Jun 23, 2016, at 1:39 PM, Xiaodi Wu  wrote:
> 
> Good to know. I absolutely agree that the gains to be had here wouldn't be 
> worth a one-off hack.

If people are strongly (or even mildly) opposed to removing this rule, we can 
give some thought to a more general solution. I don’t feel very strongly about 
this proposal one way or another, it’s just a bit of ugly code in 
TypeCheckType.cpp that would be nice to remove, and a developer on Twitter 
recently noticed this behavior and found it surprising.

> On Thu, Jun 23, 2016 at 15:36 Slava Pestov  > wrote:
>> On Jun 23, 2016, at 1:34 PM, Xiaodi Wu > > wrote:
>> 
>> Sorry, it's I who is saying things all wrong. I meant to ask, is it feasible 
>> to keep both behaviors but have #2 "win" over #1, instead of getting rid of 
>> behavior #1 entirely?
> 
> I suspect there might be some way, but I think it would have to be some kind 
> of one-off hack, which is not in line with our long-term goal of making the 
> type checker more maintainable and correct ‘by construction’.
> 
>> 
>> On Thu, Jun 23, 2016 at 15:30 Slava Pestov > > wrote:
>>> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu >> > wrote:
>>> 
>>> When you mention the difficulty of an alternative, is that to say that it's 
>>> not feasible for the GenericBox in the last example to be resolved as 
>>> GenericBox? From an end-user point of view, that seems to be the most 
>>> sensible behavior.
>> 
>> With my proposed change, GenericBox would be resolved as GenericBox in 
>> the last example. Right now it fails to type check.
>> 
>> Here is an example that works right now, but would not work with my proposed 
>> change:
>> 
>> struct GenericBox {
>>  // Currently Swift resolves this as ‘GenericBox’
>>  // With the new rule, we cannot infer the parameter, because there’s no 
>> expression to infer it from
>>  func combine(other: GenericBox) {
>>  …
>>  }
>> }
>> 
>> Basically the meaning of ‘GenericBox’ right now depends on whether it 
>> appears inside its own definition or extension thereof, or not. The behavior 
>> when it appears elsewhere is more general — we infer the parameters from the 
>> surrounding expression, instead of assuming they’re equal to the context 
>> parameters.
>> 
>> This is a subtle change — definitely let me know if I’m not explaining it 
>> well.
>> 
>> Slava
>> 
>>> On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> Simpler interpretation of a reference to a generic type with no arguments
>>> 
>>> Proposal: SE- 
>>> 
>>> Author: Slava Pestov 
>>> Status: Awaiting review
>>> Review manager: TBD
>>>  
>>> Introduction
>>> 
>>> This proposal cleans up the semantics of a reference to a generic type when 
>>> no generic arguments are applied.
>>> 
>>> Swift-evolution thread: Discussion thread topic for that proposal 
>>> 
>>>  
>>> Motivation
>>> 
>>> Right now, we allow a generic type to be referenced with no generic 
>>> arguments applied in a handful of special cases. The two primary rules here 
>>> are the following:
>>> 
>>> If the scope from which the reference is made is nested inside the 
>>> definition of the type or an extension thereof, omitting generic arguments 
>>> just means to implicitly apply the arguments from context.
>>> 
>>> For example,
>>> 
>>> struct GenericBox {
>>>   let contents: Contents
>>> 
>>>   // Equivalent to: func clone() -> GenericBox
>>>   func clone() -> GenericBox {
>>> return GenericBox(contents: contents)
>>>   }
>>> }
>>> 
>>> extension GenericBox {
>>>   func print() {
>>> // Equivalent to: let cloned: GenericBox
>>> let cloned: GenericBox = clone()
>>> print(cloned.contents)
>>>   }
>>> }
>>> If the type is referenced from an unrelated scope, we attempt to infer the 
>>> generic parameters.
>>> 
>>> For example,
>>> 
>>> func makeABox() -> GenericBox {
>>>   // Equivalent to: GenericBox(contents: 123)
>>>   return GenericBox(contents: 123)
>>> }
>>> The problem appears when the user expects the second behavior, but instead 
>>> encounters the first. For example, the following does not type check:
>>> 
>>> extension GenericBox {
>>> 
>>>   func transform(f: Contents -> T) -> GenericBox {
>>> // We resolve 'GenericBox' as 'GenericBox', rather than
>>> // inferring the type parameter
>>> return GenericBox(contents: f(contents))
>>>   }
>>> }
>>>  
>>> 

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Xiaodi Wu via swift-evolution]

Good to know. I absolutely agree that the gains to be had here wouldn't be
worth a one-off hack.
On Thu, Jun 23, 2016 at 15:36 Slava Pestov  wrote:

> On Jun 23, 2016, at 1:34 PM, Xiaodi Wu  wrote:
>
> Sorry, it's I who is saying things all wrong. I meant to ask, is it
> feasible to keep both behaviors but have #2 "win" over #1, instead of
> getting rid of behavior #1 entirely?
>
>
> I suspect there might be some way, but I think it would have to be some
> kind of one-off hack, which is not in line with our long-term goal of
> making the type checker more maintainable and correct ‘by construction’.
>
>
> On Thu, Jun 23, 2016 at 15:30 Slava Pestov  wrote:
>
>> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu  wrote:
>>
>> When you mention the difficulty of an alternative, is that to say that
>> it's not feasible for the GenericBox in the last example to be resolved as
>> GenericBox? From an end-user point of view, that seems to be the most
>> sensible behavior.
>>
>>
>> With my proposed change, GenericBox would be resolved as GenericBox in
>> the last example. Right now it fails to type check.
>>
>> Here is an example that works right now, but would not work with my
>> proposed change:
>>
>> struct GenericBox {
>> // Currently Swift resolves this as ‘GenericBox’
>> // With the new rule, we cannot infer the parameter, because there’s no
>> expression to infer it from
>> func combine(other: GenericBox) {
>> …
>> }
>> }
>>
>> Basically the meaning of ‘GenericBox’ right now depends on whether it
>> appears inside its own definition or extension thereof, or not. The
>> behavior when it appears elsewhere is more general — we infer the
>> parameters from the surrounding expression, instead of assuming they’re
>> equal to the context parameters.
>>
>> This is a subtle change — definitely let me know if I’m not explaining it
>> well.
>>
>> Slava
>>
>> On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Simpler interpretation of a reference to a generic type with no arguments
>>>
>>>- Proposal: SE-
>>>
>>> 
>>>- Author: Slava Pestov 
>>>- Status: Awaiting review
>>>- Review manager: TBD
>>>
>>>
>>> 
>>> Introduction
>>>
>>> This proposal cleans up the semantics of a reference to a generic type
>>> when no generic arguments are applied.
>>>
>>> Swift-evolution thread: Discussion thread topic for that proposal
>>> 
>>>
>>> 
>>> Motivation
>>>
>>> Right now, we allow a generic type to be referenced with no generic
>>> arguments applied in a handful of special cases. The two primary rules here
>>> are the following:
>>>
>>>-
>>>
>>>If the scope from which the reference is made is nested inside the
>>>definition of the type or an extension thereof, omitting generic 
>>> arguments
>>>just means to implicitly apply the arguments from context.
>>>
>>>For example,
>>>
>>> struct GenericBox {
>>>   let contents: Contents
>>>
>>>   // Equivalent to: func clone() -> GenericBox
>>>   func clone() -> GenericBox {
>>> return GenericBox(contents: contents)
>>>   }
>>> }
>>> extension GenericBox {
>>>   func print() {
>>> // Equivalent to: let cloned: GenericBox
>>> let cloned: GenericBox = clone()
>>> print(cloned.contents)
>>>   }
>>> }
>>>
>>>
>>>-
>>>
>>>If the type is referenced from an unrelated scope, we attempt to
>>>infer the generic parameters.
>>>
>>>For example,
>>>
>>> func makeABox() -> GenericBox {
>>>   // Equivalent to: GenericBox(contents: 123)
>>>   return GenericBox(contents: 123)
>>> }
>>>
>>> The problem appears when the user expects the second behavior, but
>>> instead encounters the first. For example, the following does not type
>>> check:
>>>
>>> extension GenericBox {
>>>
>>>   func transform(f: Contents -> T) -> GenericBox {
>>> // We resolve 'GenericBox' as 'GenericBox', rather than
>>> // inferring the type parameter
>>> return GenericBox(contents: f(contents))
>>>   }
>>> }
>>>
>>>
>>> Proposed
>>> solution
>>>
>>> The proposed solution is to remove the first rule altogether. If the
>>> generic parameters cannot be inferred from context, they must be specified
>>> explicitly with the usual Type syntax.
>>>
>>> Detailed
>>> design
>>>
>>> This really just involves removing an existing piece of logic from the
>>> type resolver code.
>>>
>>> 

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Slava Pestov via swift-evolution]

> On Jun 23, 2016, at 1:34 PM, Xiaodi Wu  wrote:
> 
> Sorry, it's I who is saying things all wrong. I meant to ask, is it feasible 
> to keep both behaviors but have #2 "win" over #1, instead of getting rid of 
> behavior #1 entirely?

I suspect there might be some way, but I think it would have to be some kind of 
one-off hack, which is not in line with our long-term goal of making the type 
checker more maintainable and correct ‘by construction’.

> 
> On Thu, Jun 23, 2016 at 15:30 Slava Pestov  > wrote:
>> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu > > wrote:
>> 
>> When you mention the difficulty of an alternative, is that to say that it's 
>> not feasible for the GenericBox in the last example to be resolved as 
>> GenericBox? From an end-user point of view, that seems to be the most 
>> sensible behavior.
> 
> With my proposed change, GenericBox would be resolved as GenericBox in the 
> last example. Right now it fails to type check.
> 
> Here is an example that works right now, but would not work with my proposed 
> change:
> 
> struct GenericBox {
>   // Currently Swift resolves this as ‘GenericBox’
>   // With the new rule, we cannot infer the parameter, because there’s no 
> expression to infer it from
>   func combine(other: GenericBox) {
>   …
>   }
> }
> 
> Basically the meaning of ‘GenericBox’ right now depends on whether it appears 
> inside its own definition or extension thereof, or not. The behavior when it 
> appears elsewhere is more general — we infer the parameters from the 
> surrounding expression, instead of assuming they’re equal to the context 
> parameters.
> 
> This is a subtle change — definitely let me know if I’m not explaining it 
> well.
> 
> Slava
> 
>> On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Simpler interpretation of a reference to a generic type with no arguments
>> 
>> Proposal: SE- 
>> 
>> Author: Slava Pestov 
>> Status: Awaiting review
>> Review manager: TBD
>>  
>> Introduction
>> 
>> This proposal cleans up the semantics of a reference to a generic type when 
>> no generic arguments are applied.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal 
>> 
>>  
>> Motivation
>> 
>> Right now, we allow a generic type to be referenced with no generic 
>> arguments applied in a handful of special cases. The two primary rules here 
>> are the following:
>> 
>> If the scope from which the reference is made is nested inside the 
>> definition of the type or an extension thereof, omitting generic arguments 
>> just means to implicitly apply the arguments from context.
>> 
>> For example,
>> 
>> struct GenericBox {
>>   let contents: Contents
>> 
>>   // Equivalent to: func clone() -> GenericBox
>>   func clone() -> GenericBox {
>> return GenericBox(contents: contents)
>>   }
>> }
>> 
>> extension GenericBox {
>>   func print() {
>> // Equivalent to: let cloned: GenericBox
>> let cloned: GenericBox = clone()
>> print(cloned.contents)
>>   }
>> }
>> If the type is referenced from an unrelated scope, we attempt to infer the 
>> generic parameters.
>> 
>> For example,
>> 
>> func makeABox() -> GenericBox {
>>   // Equivalent to: GenericBox(contents: 123)
>>   return GenericBox(contents: 123)
>> }
>> The problem appears when the user expects the second behavior, but instead 
>> encounters the first. For example, the following does not type check:
>> 
>> extension GenericBox {
>> 
>>   func transform(f: Contents -> T) -> GenericBox {
>> // We resolve 'GenericBox' as 'GenericBox', rather than
>> // inferring the type parameter
>> return GenericBox(contents: f(contents))
>>   }
>> }
>>  
>> Proposed
>>  solution
>> 
>> The proposed solution is to remove the first rule altogether. If the generic 
>> parameters cannot be inferred from context, they must be specified 
>> explicitly with the usual Type syntax.
>> 
>>  
>> Detailed
>>  design
>> 
>> This really just involves removing an existing piece of logic from the type 
>> resolver code.
>> 
>>  
>> Impact
>>  on existing code
>> 
>> This will have a small impact on existing code that uses a pattern similar 
>> to the above.
>> 
>>  
>> 

Re: [swift-evolution] Prohibit invisible characters in identifier names

[James Hillhouse via swift-evolution]

Thanks Xiaodi. That’s a relief to know.


> On Jun 23, 2016, at 3:32 PM, Xiaodi Wu  wrote:
> 
> FWIW, Josh's example would be fixed whether we prohibit or ignore invisible 
> characters, but there are other potential strings for which prohibition would 
> be more secure.
> 
> On Thu, Jun 23, 2016 at 15:27 James Hillhouse  > wrote:
> +1 on this. Josh Wisenbaker’s example says enough. Yikes!
> 
>> On Jun 23, 2016, at 3:18 PM, David Sweeris via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> +1
>> I didn't even know there were any invisible characters until this thread 
>> came up.
>> 
>> - Dave Sweeris
>> 
>> On Jun 23, 2016, at 15:13, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro >> > wrote:
>>> 
>>> > On 23 Jun 2016, at 20:43, Xiaodi Wu >> > > wrote:
>>> > That's cool, although my preferred solution would be more closely aligned 
>>> > with UAX #31: overtly disallow the glyphs in Table 4 (instead of ignoring 
>>> > them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX 
>>> > #31, then afterwards internally represent the identifier as its 
>>> > NFC-normalized string.
>>> 
>>> Explicitly disallowing them was my initial idea, but I think it would end 
>>> up being a confusing error for users to encounter. Ignoring the invisible 
>>> characters and leaving it up to a linter to remove them is less likely to 
>>> cause confusion for users.
>>> 
>>> I'll be sure to describe the alternative of explicitly prohibiting them in 
>>> the proposal though.
>>> 
>>> I would strongly urge you to propose explicitly prohibiting them just as 
>>> UAX #31 recommends. Their reasoning is that these characters, which include 
>>> those that reverse text direction or control joining, can cause one 
>>> identifier to be maliciously changed to look like another. If you ignore 
>>> these characters instead of prohibiting them, an identifier that visually 
>>> appears as one string could in fact be a different one to the compiler.
>>> 
>>> Moreover, a compiler error can be made helpful by saying that the offending 
>>> character is potentially invisible and it can come with a fix-it to remove 
>>> the offending character. I don't think that would confuse the user at all. 
>>> It would be more confusing if invisible characters that caused one thing to 
>>> look identical to another were silently permitted.
>>> 
>>> 
>>> Sincerely,
>>> João Pinheiro
>>> 
>>> ___
>>> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Xiaodi Wu via swift-evolution]

Sorry, it's I who is saying things all wrong. I meant to ask, is it
feasible to keep both behaviors but have #2 "win" over #1, instead of
getting rid of behavior #1 entirely?

On Thu, Jun 23, 2016 at 15:30 Slava Pestov  wrote:

> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu  wrote:
>
> When you mention the difficulty of an alternative, is that to say that
> it's not feasible for the GenericBox in the last example to be resolved as
> GenericBox? From an end-user point of view, that seems to be the most
> sensible behavior.
>
>
> With my proposed change, GenericBox would be resolved as GenericBox in
> the last example. Right now it fails to type check.
>
> Here is an example that works right now, but would not work with my
> proposed change:
>
> struct GenericBox {
> // Currently Swift resolves this as ‘GenericBox’
> // With the new rule, we cannot infer the parameter, because there’s no
> expression to infer it from
> func combine(other: GenericBox) {
> …
> }
> }
>
> Basically the meaning of ‘GenericBox’ right now depends on whether it
> appears inside its own definition or extension thereof, or not. The
> behavior when it appears elsewhere is more general — we infer the
> parameters from the surrounding expression, instead of assuming they’re
> equal to the context parameters.
>
> This is a subtle change — definitely let me know if I’m not explaining it
> well.
>
> Slava
>
> On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Simpler interpretation of a reference to a generic type with no arguments
>>
>>- Proposal: SE-
>>
>> 
>>- Author: Slava Pestov 
>>- Status: Awaiting review
>>- Review manager: TBD
>>
>>
>> 
>> Introduction
>>
>> This proposal cleans up the semantics of a reference to a generic type
>> when no generic arguments are applied.
>>
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>>
>> 
>> Motivation
>>
>> Right now, we allow a generic type to be referenced with no generic
>> arguments applied in a handful of special cases. The two primary rules here
>> are the following:
>>
>>-
>>
>>If the scope from which the reference is made is nested inside the
>>definition of the type or an extension thereof, omitting generic arguments
>>just means to implicitly apply the arguments from context.
>>
>>For example,
>>
>> struct GenericBox {
>>   let contents: Contents
>>
>>   // Equivalent to: func clone() -> GenericBox
>>   func clone() -> GenericBox {
>> return GenericBox(contents: contents)
>>   }
>> }
>> extension GenericBox {
>>   func print() {
>> // Equivalent to: let cloned: GenericBox
>> let cloned: GenericBox = clone()
>> print(cloned.contents)
>>   }
>> }
>>
>>
>>-
>>
>>If the type is referenced from an unrelated scope, we attempt to
>>infer the generic parameters.
>>
>>For example,
>>
>> func makeABox() -> GenericBox {
>>   // Equivalent to: GenericBox(contents: 123)
>>   return GenericBox(contents: 123)
>> }
>>
>> The problem appears when the user expects the second behavior, but
>> instead encounters the first. For example, the following does not type
>> check:
>>
>> extension GenericBox {
>>
>>   func transform(f: Contents -> T) -> GenericBox {
>> // We resolve 'GenericBox' as 'GenericBox', rather than
>> // inferring the type parameter
>> return GenericBox(contents: f(contents))
>>   }
>> }
>>
>>
>> Proposed
>> solution
>>
>> The proposed solution is to remove the first rule altogether. If the
>> generic parameters cannot be inferred from context, they must be specified
>> explicitly with the usual Type syntax.
>>
>> Detailed
>> design
>>
>> This really just involves removing an existing piece of logic from the
>> type resolver code.
>>
>> Impact
>> on existing code
>>
>> This will have a small impact on existing code that uses a pattern
>> similar to the above.
>>
>> Alternatives
>> considered
>> Status
>> quo
>>
>> We could keep the current behavior, but one can argue it is not very
>> useful, and adds a special case where one is not needed.
>>
>> 

Re: [swift-evolution] Prohibit invisible characters in identifier names

[Xiaodi Wu via swift-evolution]

FWIW, Josh's example would be fixed whether we prohibit or ignore invisible
characters, but there are other potential strings for which prohibition
would be more secure.

On Thu, Jun 23, 2016 at 15:27 James Hillhouse 
wrote:

> +1 on this. Josh Wisenbaker’s example says enough. Yikes!
>
> On Jun 23, 2016, at 3:18 PM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +1
> I didn't even know there were any invisible characters until this thread
> came up.
>
> - Dave Sweeris
>
> On Jun 23, 2016, at 15:13, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro 
> wrote:
>
>>
>> > On 23 Jun 2016, at 20:43, Xiaodi Wu  wrote:
>> > That's cool, although my preferred solution would be more closely
>> aligned with UAX #31: overtly disallow the glyphs in Table 4 (instead of
>> ignoring them) except in the specific scenarios for ZWJ and ZWNJ identified
>> in UAX #31, then afterwards internally represent the identifier as its
>> NFC-normalized string.
>>
>> Explicitly disallowing them was my initial idea, but I think it would end
>> up being a confusing error for users to encounter. Ignoring the invisible
>> characters and leaving it up to a linter to remove them is less likely to
>> cause confusion for users.
>>
>> I'll be sure to describe the alternative of explicitly prohibiting them
>> in the proposal though.
>>
>
> I would strongly urge you to propose explicitly prohibiting them just as
> UAX #31 recommends. Their reasoning is that these characters, which include
> those that reverse text direction or control joining, can cause one
> identifier to be maliciously changed to look like another. If you ignore
> these characters instead of prohibiting them, an identifier that visually
> appears as one string could in fact be a different one to the compiler.
>
> Moreover, a compiler error can be made helpful by saying that the
> offending character is potentially invisible and it can come with a fix-it
> to remove the offending character. I don't think that would confuse the
> user at all. It would be more confusing if invisible characters that caused
> one thing to look identical to another were silently permitted.
>
>
>> Sincerely,
>> João Pinheiro
>
>
> ___
> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Slava Pestov via swift-evolution]

> On Jun 23, 2016, at 1:30 PM, Slava Pestov  wrote:
> 
> 
>> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu > > wrote:
>> 
>> When you mention the difficulty of an alternative, is that to say that it's 
>> not feasible for the GenericBox in the last example to be resolved as 
>> GenericBox? From an end-user point of view, that seems to be the most 
>> sensible behavior.
> 
> With my proposed change, GenericBox would be resolved as GenericBox in the 
> last example. Right now it fails to type check.

This should make it clearer:

struct GenericBox {
  let contents: Contents

  func transform(f: (Contents) -> Result) -> GenericBox {
// If you change this to just ‘GenericBox(contents: …)’, it does not type 
check
return GenericBox(contents: f(contents))
  }
}

func transform(box: GenericBox,
  f: (Contents) -> Result) -> GenericBox {
  // But this is totally fine!
  return GenericBox(contents: f(box.contents))
}

I suspect most people do not expect the first case to fail, and it is not 
immediately obvious why it fails when the second example type checks.

> 
> Here is an example that works right now, but would not work with my proposed 
> change:
> 
> struct GenericBox {
>   // Currently Swift resolves this as ‘GenericBox’
>   // With the new rule, we cannot infer the parameter, because there’s no 
> expression to infer it from
>   func combine(other: GenericBox) {
>   …
>   }
> }
> 
> Basically the meaning of ‘GenericBox’ right now depends on whether it appears 
> inside its own definition or extension thereof, or not. The behavior when it 
> appears elsewhere is more general — we infer the parameters from the 
> surrounding expression, instead of assuming they’re equal to the context 
> parameters.
> 
> This is a subtle change — definitely let me know if I’m not explaining it 
> well.
> 
> Slava
> 
>> On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Simpler interpretation of a reference to a generic type with no arguments
>> 
>> Proposal: SE- 
>> 
>> Author: Slava Pestov 
>> Status: Awaiting review
>> Review manager: TBD
>>  
>> Introduction
>> 
>> This proposal cleans up the semantics of a reference to a generic type when 
>> no generic arguments are applied.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal 
>> 
>>  
>> Motivation
>> 
>> Right now, we allow a generic type to be referenced with no generic 
>> arguments applied in a handful of special cases. The two primary rules here 
>> are the following:
>> 
>> If the scope from which the reference is made is nested inside the 
>> definition of the type or an extension thereof, omitting generic arguments 
>> just means to implicitly apply the arguments from context.
>> 
>> For example,
>> 
>> struct GenericBox {
>>   let contents: Contents
>> 
>>   // Equivalent to: func clone() -> GenericBox
>>   func clone() -> GenericBox {
>> return GenericBox(contents: contents)
>>   }
>> }
>> 
>> extension GenericBox {
>>   func print() {
>> // Equivalent to: let cloned: GenericBox
>> let cloned: GenericBox = clone()
>> print(cloned.contents)
>>   }
>> }
>> If the type is referenced from an unrelated scope, we attempt to infer the 
>> generic parameters.
>> 
>> For example,
>> 
>> func makeABox() -> GenericBox {
>>   // Equivalent to: GenericBox(contents: 123)
>>   return GenericBox(contents: 123)
>> }
>> The problem appears when the user expects the second behavior, but instead 
>> encounters the first. For example, the following does not type check:
>> 
>> extension GenericBox {
>> 
>>   func transform(f: Contents -> T) -> GenericBox {
>> // We resolve 'GenericBox' as 'GenericBox', rather than
>> // inferring the type parameter
>> return GenericBox(contents: f(contents))
>>   }
>> }
>>  
>> Proposed
>>  solution
>> 
>> The proposed solution is to remove the first rule altogether. If the generic 
>> parameters cannot be inferred from context, they must be specified 
>> explicitly with the usual Type syntax.
>> 
>>  
>> Detailed
>>  design
>> 
>> This really just involves removing an existing piece of logic from the type 
>> resolver code.
>> 
>>  
>> Impact
>>  on existing code
>> 
>> This will have a small i

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Slava Pestov via swift-evolution]

> On Jun 23, 2016, at 1:27 PM, Xiaodi Wu  wrote:
> 
> When you mention the difficulty of an alternative, is that to say that it's 
> not feasible for the GenericBox in the last example to be resolved as 
> GenericBox? From an end-user point of view, that seems to be the most 
> sensible behavior.

With my proposed change, GenericBox would be resolved as GenericBox in the 
last example. Right now it fails to type check.

Here is an example that works right now, but would not work with my proposed 
change:

struct GenericBox {
// Currently Swift resolves this as ‘GenericBox’
// With the new rule, we cannot infer the parameter, because there’s no 
expression to infer it from
func combine(other: GenericBox) {
…
}
}

Basically the meaning of ‘GenericBox’ right now depends on whether it appears 
inside its own definition or extension thereof, or not. The behavior when it 
appears elsewhere is more general — we infer the parameters from the 
surrounding expression, instead of assuming they’re equal to the context 
parameters.

This is a subtle change — definitely let me know if I’m not explaining it well.

Slava

> On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Simpler interpretation of a reference to a generic type with no arguments
> 
> Proposal: SE- 
> 
> Author: Slava Pestov 
> Status: Awaiting review
> Review manager: TBD
>  
> Introduction
> 
> This proposal cleans up the semantics of a reference to a generic type when 
> no generic arguments are applied.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> Right now, we allow a generic type to be referenced with no generic arguments 
> applied in a handful of special cases. The two primary rules here are the 
> following:
> 
> If the scope from which the reference is made is nested inside the definition 
> of the type or an extension thereof, omitting generic arguments just means to 
> implicitly apply the arguments from context.
> 
> For example,
> 
> struct GenericBox {
>   let contents: Contents
> 
>   // Equivalent to: func clone() -> GenericBox
>   func clone() -> GenericBox {
> return GenericBox(contents: contents)
>   }
> }
> 
> extension GenericBox {
>   func print() {
> // Equivalent to: let cloned: GenericBox
> let cloned: GenericBox = clone()
> print(cloned.contents)
>   }
> }
> If the type is referenced from an unrelated scope, we attempt to infer the 
> generic parameters.
> 
> For example,
> 
> func makeABox() -> GenericBox {
>   // Equivalent to: GenericBox(contents: 123)
>   return GenericBox(contents: 123)
> }
> The problem appears when the user expects the second behavior, but instead 
> encounters the first. For example, the following does not type check:
> 
> extension GenericBox {
> 
>   func transform(f: Contents -> T) -> GenericBox {
> // We resolve 'GenericBox' as 'GenericBox', rather than
> // inferring the type parameter
> return GenericBox(contents: f(contents))
>   }
> }
>  
> Proposed
>  solution
> 
> The proposed solution is to remove the first rule altogether. If the generic 
> parameters cannot be inferred from context, they must be specified explicitly 
> with the usual Type syntax.
> 
>  
> Detailed
>  design
> 
> This really just involves removing an existing piece of logic from the type 
> resolver code.
> 
>  
> Impact
>  on existing code
> 
> This will have a small impact on existing code that uses a pattern similar to 
> the above.
> 
>  
> Alternatives
>  considered
> 
>  
> Status
>  quo
> 
> We could keep the current behavior, but one can argue it is not very useful, 
> and adds a special case where one is not needed.
> 
>  
> More
>  complex inference of generic parameters
> 
> We could attempt to unify the two rules for resolving a reference to a 
> generic type with no arguments, however this presents theoretical 
> difficulties with our constraint 

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Xiaodi Wu via swift-evolution]

When you mention the difficulty of an alternative, is that to say that it's
not feasible for the GenericBox in the last example to be resolved as
GenericBox? From an end-user point of view, that seems to be the most
sensible behavior.
On Thu, Jun 23, 2016 at 15:14 Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Simpler interpretation of a reference to a generic type with no arguments
>
>- Proposal: SE-
>
> 
>- Author: Slava Pestov 
>- Status: Awaiting review
>- Review manager: TBD
>
>
> 
> Introduction
>
> This proposal cleans up the semantics of a reference to a generic type
> when no generic arguments are applied.
>
> Swift-evolution thread: Discussion thread topic for that proposal
> 
>
> 
> Motivation
>
> Right now, we allow a generic type to be referenced with no generic
> arguments applied in a handful of special cases. The two primary rules here
> are the following:
>
>-
>
>If the scope from which the reference is made is nested inside the
>definition of the type or an extension thereof, omitting generic arguments
>just means to implicitly apply the arguments from context.
>
>For example,
>
> struct GenericBox {
>   let contents: Contents
>
>   // Equivalent to: func clone() -> GenericBox
>   func clone() -> GenericBox {
> return GenericBox(contents: contents)
>   }
> }
> extension GenericBox {
>   func print() {
> // Equivalent to: let cloned: GenericBox
> let cloned: GenericBox = clone()
> print(cloned.contents)
>   }
> }
>
>
>-
>
>If the type is referenced from an unrelated scope, we attempt to infer
>the generic parameters.
>
>For example,
>
> func makeABox() -> GenericBox {
>   // Equivalent to: GenericBox(contents: 123)
>   return GenericBox(contents: 123)
> }
>
> The problem appears when the user expects the second behavior, but instead
> encounters the first. For example, the following does not type check:
>
> extension GenericBox {
>
>   func transform(f: Contents -> T) -> GenericBox {
> // We resolve 'GenericBox' as 'GenericBox', rather than
> // inferring the type parameter
> return GenericBox(contents: f(contents))
>   }
> }
>
>
> Proposed
> solution
>
> The proposed solution is to remove the first rule altogether. If the
> generic parameters cannot be inferred from context, they must be specified
> explicitly with the usual Type syntax.
>
> Detailed
> design
>
> This really just involves removing an existing piece of logic from the
> type resolver code.
>
> Impact
> on existing code
>
> This will have a small impact on existing code that uses a pattern similar
> to the above.
>
> Alternatives
> considered
> Status
> quo
>
> We could keep the current behavior, but one can argue it is not very
> useful, and adds a special case where one is not needed.
>
> More
> complex inference of generic parameters
> We could attempt to unify the two rules for resolving a reference to a
> generic type with no arguments, however this presents theoretical
> difficulties with our constraint solver design. Even if it were easy to
> implement, it would increase type checking type by creating new
> possibilities to consider, with very little actual benefit.
> ___
> 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] Prohibit invisible characters in identifier names

[James Hillhouse via swift-evolution]

+1 on this. Josh Wisenbaker’s example says enough. Yikes!

> On Jun 23, 2016, at 3:18 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> +1
> I didn't even know there were any invisible characters until this thread came 
> up.
> 
> - Dave Sweeris
> 
> On Jun 23, 2016, at 15:13, Xiaodi Wu via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro > > wrote:
>> 
>> > On 23 Jun 2016, at 20:43, Xiaodi Wu > > > wrote:
>> > That's cool, although my preferred solution would be more closely aligned 
>> > with UAX #31: overtly disallow the glyphs in Table 4 (instead of ignoring 
>> > them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX 
>> > #31, then afterwards internally represent the identifier as its 
>> > NFC-normalized string.
>> 
>> Explicitly disallowing them was my initial idea, but I think it would end up 
>> being a confusing error for users to encounter. Ignoring the invisible 
>> characters and leaving it up to a linter to remove them is less likely to 
>> cause confusion for users.
>> 
>> I'll be sure to describe the alternative of explicitly prohibiting them in 
>> the proposal though.
>> 
>> I would strongly urge you to propose explicitly prohibiting them just as UAX 
>> #31 recommends. Their reasoning is that these characters, which include 
>> those that reverse text direction or control joining, can cause one 
>> identifier to be maliciously changed to look like another. If you ignore 
>> these characters instead of prohibiting them, an identifier that visually 
>> appears as one string could in fact be a different one to the compiler.
>> 
>> Moreover, a compiler error can be made helpful by saying that the offending 
>> character is potentially invisible and it can come with a fix-it to remove 
>> the offending character. I don't think that would confuse the user at all. 
>> It would be more confusing if invisible characters that caused one thing to 
>> look identical to another were silently permitted.
>> 
>> 
>> Sincerely,
>> João Pinheiro
>> 
>> ___
>> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jun 23, 2016, at 3:12 PM, Slava Pestov  wrote:
> 
> Great to hear some feedback so quickly, especially about something so mundane.

You caught me at the right time I guess.  :)  

This kind of thing is only mundane until your code doesn't behave as you 
expect.  Then it can become downright maddening!  I would never in a million 
years guess that the return type would affect the interpretation of self in 
this way.

BTW, allowing Self to appear in covarying positions in argument types and the 
protocol conformances this will enable are a very nice bonus (even if it 
doesn't happen right away).

> 
> I suspect the real reason it doesn’t work this way now is that ‘Self’ is not 
> fully plumbed through. In particular, if a closure captures the ‘Self’ type, 
> IRGen does not properly codegen it, causing compile-time or run-time crashes:
> 
> class MyClass {
>   func foo(x: Int) -> Self {
> 
>   // Crash!
>   _ = { print(self); print(x) }
> 
>   return self
>   }
> 
>   func bar(x: Int) -> MyClass {
> 
>   // OK!
>   _ = { print(self); print(x) }
> 
>   return self
>   }
> }
> 
> Assertion failed: (LocalSelf && "no local self metadata"), function 
> getLocalSelfMetadata, file /Users/slava/new/swift/lib/IRGen/GenType.cpp, line 
> 1805.
> 0  swift0x000114d5276e 
> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46
> 1  swift0x000114d52c99 
> PrintStackTraceSignalHandler(void*) + 25
> 2  swift0x000114d4efc9 llvm::sys::RunSignalHandlers() 
> + 425
> 3  swift0x000114d53312 SignalHandler(int) + 354
> 4  libsystem_platform.dylib 0x7fffc438a01a _sigtramp + 26
> 5  libsystem_platform.dylib 0x507ca710 _sigtramp + 2353268496
> 6  swift0x000114d52cbb raise + 27
> 7  swift0x000114d52d62 abort + 18
> 8  swift0x000114d52d4e __assert_rtn + 126
> 9  swift0x00010f6e8524 
> swift::irgen::IRGenFunction::getLocalSelfMetadata() + 100
> 
> This comes up most frequently with the ‘weak self / strong self’ dance.
> 
> I’m going to fix this bug really soon, and it seems logical to deal with the 
> language wart as well. We need the IRGen fix for SE-0086 as well in any case.
> 
> Slava
> 
>> On Jun 23, 2016, at 1:08 PM, Matthew Johnson  wrote:
>> 
>> +1.  I have not encountered this issue myself but it looks like something 
>> that would cause a lot of head scratching if I had.  It is also something 
>> that I am unlikely to remember immediately if I run into it in the future.  
>> The current behavior appears broken to me.  It will be great to have it 
>> fixed.
>> 
>>> On Jun 23, 2016, at 2:53 PM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> Consistent formal type for 'self' in class methods
>>> Proposal: SE-
>>> Author: Slava Pestov
>>> Status: Awaiting review
>>> Review manager: TBD
>>> Introduction
>>> 
>>> This proposal makes the self value behave consistently whether or not it is 
>>> used from a method with a Self return type.
>>> 
>>> Swift-evolution thread: Discussion thread topic for that proposal
>>> 
>>> Motivation
>>> 
>>> Right now, we exhibit inconsistent behavior when self is used as an 
>>> argument to a generic function, violating the principle of least surprise.
>>> 
>>> Consider the following code:
>>> 
>>> class Base {
>>>   @discardableResult
>>>   func methodWithDynamicSelf() -> Self {
>>> doSomething(self)
>>> return self
>>>   }
>>> 
>>>   func methodWithoutDynamicSelf() {
>>> doSomething(self)
>>>   }
>>> }
>>> 
>>> class Derived : Base {}
>>> 
>>> func doSomething(_ t: T) {
>>>   print(T.self)
>>> }
>>> 
>>> Base().methodWithDynamicSelf()
>>> Base().methodWithoutDynamicSelf()
>>> 
>>> Derived().methodWithDynamicSelf()
>>> Derived().methodWithoutDynamicSelf()
>>> Currently, it prints the following output:
>>> 
>>> Base
>>> Base
>>> Derived
>>> Base
>>> Note that there's no inconsistency when the method is called on the base 
>>> class. When called on the derived class however, we see that in a method 
>>> with a dynamic Self return type, the type of self is Derived, whereas in a 
>>> method with any other return type, the type of self is Base.
>>> 
>>> Proposed solution
>>> 
>>> The proposal is to change the type of self to always be Self, which can be 
>>> thought of as a special generic type parameter bound to the dynamic type of 
>>> the instance.
>>> 
>>> With this proposal, the above code will instead produce the following:
>>> 
>>> Base
>>> Base
>>> Derived
>>> Derived
>>> Here, the type of self would always be Derived when called on an instance 
>>> of the derived class.
>>> 
>>> Of course a more useful program could instead do something with the type 
>>> parameter T, such as constraining it to a protocol or a class with a 
>>> required initializer, and then using t

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

[James Hillhouse via swift-evolution]

I’m going to register a -1 on this proposal. I appreciate the work that went 
into it, but I just don’t think any advantages for the developer community as a 
whole weight enough to warrant the change.

> On Jun 23, 2016, at 4:41 AM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
> 
>> On 22 Jun 2016, at 17:27, Brandon Knope  wrote:
>> 
>> Of course \ is not needed a lot but when it is, *it is inconvenient for 
>> *some* people*. I am not making this up. You can cite several other users 
>> from this very thread.
> 
> That’s the point. Convenient key stroke sequences should be used for things 
> you need a lot before things you don’t use a lot. 
> 
>> 
>> I tried showing that it is quite distant on the keyboard from where the 
>> user’s hands rest. I tried showing that there are other keys at their finger 
>> tips where their hand is usually resting.
>> 
>> 1. Do I know every international keyboard layout? No.
>> 2. Are we pretending that \ was picked because it was easier for 
>> international users? If I am wrong, I would love to hear more…else let’s not 
>> pretend that \ was the optimal key for all.
> 
> No, it was picked because it is the escape character for strings. The escape 
> character(s) for strings need to be few in number (one is ideal IMO) and 
> characters that you aren’t likely to need to type in a string as literals. $ 
> is a particularly bad choice due to its popularity as a currency symbol.

Changing this would add more syntax, make layers in usage where one character 
now exist, and does so without offering a large material advantage, imho.

> 
>> 
>> Like I have said repeatedly…I don’t care if \ is removed. At this point we 
>> are wasting other people’s time. I have just tried to be a voice for those 
>> that find it awkward and inconvenient.
> 
> I would challenge the claim that on a US keyboard or a British keyboard, the 
> \ key is inconvenient to type. In both cases, you don’t even have to press 
> the shift key. If you are a touch typist (I’m not), it’s a slight stretch for 
> the right hand, but no more so than the return key or backspace (I use 
> backspace *a lot*).

Compared to typing Obj-C' [], which was when was tired “=“ “delete” or “]” “\”, 
Swift in general, including \(), is a breeze. 

> 
> However, I do find the \( *combination* a little awkward but this is because 
> of the way I normally type the (, but I would find having to type \$ every 
> time I wanted a dollar sign intensely annoying because it is so unnecessary.
> 
> 
>> I tried not to base this just on opinion but on some *evidence*, but 
>> apparently that isn’t sufficient enough for some.
> 
> And I was just trying to point out that the evidence you presented does not 
> show what you think it does. If you present evidence, I’m allowed to dispute 
> it aren’t I?
> 
>> 
>> Brandon
>> 
>> 
>>> On Jun 22, 2016, at 12:20 PM, Jeremy Pereira 
>>>  wrote:
>>> 
>>> 
 On 22 Jun 2016, at 17:02, Brandon Knope  wrote:
 
 No it shows where your hand frequently is also
>>> 
>>> And you don’t think there is a correlation between where the frequently 
>>> pressed keys are and where your hands are? If you were needing to press the 
>>> \ key a lot, there would be a hotspot over it. Then you could say “look, I 
>>> need to press this key a lot and it’s miles away from the other hotspot”. 
>>> 
 
 Brandon
 
> On Jun 22, 2016, at 12:01 PM, Jeremy Pereira 
>  wrote:
> 
> 
>> On 22 Jun 2016, at 16:41, Brandon Knope  wrote:
>> 
>> My point was not to argue for the removal of \. My point was that there 
>> is a measurable way to test the usability of such a key
> 
> 
> Your heat map doesn’t test the usability of a key, it tests the frequency 
> with which it was pressed. The fact that there was no coloured blob on 
> the backslash key just means you don’t use it very often.
> 
> 
>> 
>> Brandon
>> 
>>> On Jun 22, 2016, at 11:30 AM, Jeremy Pereira 
>>>  wrote:
>>> 
>>> I find it somewhat disturbing that we are now trying to base language 
>>> design around the layout of a US English keyboard.
>>> 
>>> “\” on my keyboard (British Macbook Pro Retina) is right next to the 
>>> return key. It’s also much closer to the parentheses characters than $ 
>>> is and (if you assume we are going to replace parentheses with braces 
>>> as was suggested upthread) right next to the brace keys. 
>>> 
>>> Anyway, your heat map evidence actually negates the argument. If it was 
>>> a frequently used key, it would have a hot spot of its own. It’s not (I 
>>> tried it on some random samples of my own code), so that implies it is 
>>> not a key that is used very often, which further implies it *should* be 
>>> a little out of the way.
>>> 
>>> *The* escape character for strings is “\”. Please let’s not introduce a 
>>> second one.
>>> 
>>> 
 On 22 Jun 2016, at 00:0

Re: [swift-evolution] Prohibit invisible characters in identifier names

[David Sweeris via swift-evolution]

+1
I didn't even know there were any invisible characters until this thread came 
up.

- Dave Sweeris

> On Jun 23, 2016, at 15:13, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro  wrote:
>> 
>> > On 23 Jun 2016, at 20:43, Xiaodi Wu  wrote:
>> > That's cool, although my preferred solution would be more closely aligned 
>> > with UAX #31: overtly disallow the glyphs in Table 4 (instead of ignoring 
>> > them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX 
>> > #31, then afterwards internally represent the identifier as its 
>> > NFC-normalized string.
>> 
>> Explicitly disallowing them was my initial idea, but I think it would end up 
>> being a confusing error for users to encounter. Ignoring the invisible 
>> characters and leaving it up to a linter to remove them is less likely to 
>> cause confusion for users.
>> 
>> I'll be sure to describe the alternative of explicitly prohibiting them in 
>> the proposal though.
> 
> I would strongly urge you to propose explicitly prohibiting them just as UAX 
> #31 recommends. Their reasoning is that these characters, which include those 
> that reverse text direction or control joining, can cause one identifier to 
> be maliciously changed to look like another. If you ignore these characters 
> instead of prohibiting them, an identifier that visually appears as one 
> string could in fact be a different one to the compiler.
> 
> Moreover, a compiler error can be made helpful by saying that the offending 
> character is potentially invisible and it can come with a fix-it to remove 
> the offending character. I don't think that would confuse the user at all. It 
> would be more confusing if invisible characters that caused one thing to look 
> identical to another were silently permitted.
> 
>> 
>> Sincerely,
>> João Pinheiro
> 
> ___
> 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] [Pitch] Make the formal type of 'self' consistent in class methods

[Sean Heber via swift-evolution]

This is certainly surprisingly behavior to me! +1

l8r
Sean


> On Jun 23, 2016, at 2:53 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Consistent formal type for 'self' in class methods
> 
>   • Proposal: SE-
>   • Author: Slava Pestov
>   • Status: Awaiting review
>   • Review manager: TBD
> 
> Introduction
> 
> This proposal makes the self value behave consistently whether or not it is 
> used from a method with a Self return type.
> 
> Swift-evolution thread: Discussion thread topic for that proposal
> 
> 
> Motivation
> 
> Right now, we exhibit inconsistent behavior when self is used as an argument 
> to a generic function, violating the principle of least surprise.
> 
> Consider the following code:
> 
> class
>  Base {
>   
> @discardableResult
> 
>   
> func methodWithDynamicSelf() ->
>  Self {
> doSomething(
> self
> )
> 
> return self
> 
>   }
> 
>   
> func methodWithoutDynamicSelf
> () {
> doSomething(
> self
> )
>   }
> }
> 
> 
> class Derived :
>  Base {}
> 
> 
> func doSomething(_ t
> : T) {
>   
> print(T.self
> )
> }
> 
> Base()
> .
> methodWithDynamicSelf()
> Base()
> .
> methodWithoutDynamicSelf()
> 
> Derived()
> .
> methodWithDynamicSelf()
> Derived()
> .methodWithoutDynamicSelf()
> Currently, it prints the following output:
> 
> Base
> Base
> Derived
> Base
> 
> Note that there's no inconsistency when the method is called on the base 
> class. When called on the derived class however, we see that in a method with 
> a dynamic Self return type, the type of self is Derived, whereas in a method 
> with any other return type, the type of self is Base.
> 
> 
> Proposed solution
> 
> The proposal is to change the type of self to always be Self, which can be 
> thought of as a special generic type parameter bound to the dynamic type of 
> the instance.
> 
> With this proposal, the above code will instead produce the following:
> 
> Base
> Base
> Derived
> Derived
> 
> Here, the type of self would always be Derived when called on an instance of 
> the derived class.
> 
> Of course a more useful program could instead do something with the type 
> parameter T, such as constraining it to a protocol or a class with a required 
> initializer, and then using the type to construct a new instance of the class.
> 
> This also dovetails nicely with SE-0068.
> 
> Finally, it opens the door to generalizing dynamic Self, allowing it to 
> appear in covariant position within parameter types:
> 
> class
>  ArtClass {
>   
> func paint(withBrush: (Self) -> ()) { ...
>  }
> }
> 
> This would allow a class to conform to a protocol with a requirement written 
> like the following, something that is currently not possible at all:
> 
> protocol
>  OddProtocol {
>   
> func weaken((Self) ->
>  (X) -> Y) -> (X) -> Y
> }
> 
> 
> Detailed design
> 
> There's really not much more to say here. The code for typing self with a 
> dynamic Self is in place already, however enabling this change might expose 
> some new bugs we have not yet encountered, because currently, methods with 
> dynamic Self return type are relatively rare.
> 
> 
> Impact on existing code
> 
> This will have a small impact on existing code that uses a pattern similar to 
> the above.
> 
> 
> Alternatives considered
> 
> One alternative is to simply do nothing, but this makes the language less 
> consistent than it could be.
> 
> ___
> 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] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

[Slava Pestov via swift-evolution]

Simpler interpretation of a reference to a generic type with no arguments

Proposal: SE- 

Author: Slava Pestov 
Status: Awaiting review
Review manager: TBD
 
Introduction

This proposal cleans up the semantics of a reference to a generic type when no 
generic arguments are applied.

Swift-evolution thread: Discussion thread topic for that proposal 

 
Motivation

Right now, we allow a generic type to be referenced with no generic arguments 
applied in a handful of special cases. The two primary rules here are the 
following:

If the scope from which the reference is made is nested inside the definition 
of the type or an extension thereof, omitting generic arguments just means to 
implicitly apply the arguments from context.

For example,

struct GenericBox {
  let contents: Contents

  // Equivalent to: func clone() -> GenericBox
  func clone() -> GenericBox {
return GenericBox(contents: contents)
  }
}

extension GenericBox {
  func print() {
// Equivalent to: let cloned: GenericBox
let cloned: GenericBox = clone()
print(cloned.contents)
  }
}
If the type is referenced from an unrelated scope, we attempt to infer the 
generic parameters.

For example,

func makeABox() -> GenericBox {
  // Equivalent to: GenericBox(contents: 123)
  return GenericBox(contents: 123)
}
The problem appears when the user expects the second behavior, but instead 
encounters the first. For example, the following does not type check:

extension GenericBox {

  func transform(f: Contents -> T) -> GenericBox {
// We resolve 'GenericBox' as 'GenericBox', rather than
// inferring the type parameter
return GenericBox(contents: f(contents))
  }
}
 
Proposed
 solution

The proposed solution is to remove the first rule altogether. If the generic 
parameters cannot be inferred from context, they must be specified explicitly 
with the usual Type syntax.

 
Detailed
 design

This really just involves removing an existing piece of logic from the type 
resolver code.

 
Impact
 on existing code

This will have a small impact on existing code that uses a pattern similar to 
the above.

 
Alternatives
 considered

 
Status
 quo

We could keep the current behavior, but one can argue it is not very useful, 
and adds a special case where one is not needed.

 
More
 complex inference of generic parameters

We could attempt to unify the two rules for resolving a reference to a generic 
type with no arguments, however this presents theoretical difficulties with our 
constraint solver design. Even if it were easy to implement, it would increase 
type checking type by creating new possibilities to consider, with very little 
actual benefit.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Prohibit invisible characters in identifier names

[Xiaodi Wu via swift-evolution]

On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro 
wrote:

>
> > On 23 Jun 2016, at 20:43, Xiaodi Wu  wrote:
> > That's cool, although my preferred solution would be more closely
> aligned with UAX #31: overtly disallow the glyphs in Table 4 (instead of
> ignoring them) except in the specific scenarios for ZWJ and ZWNJ identified
> in UAX #31, then afterwards internally represent the identifier as its
> NFC-normalized string.
>
> Explicitly disallowing them was my initial idea, but I think it would end
> up being a confusing error for users to encounter. Ignoring the invisible
> characters and leaving it up to a linter to remove them is less likely to
> cause confusion for users.
>
> I'll be sure to describe the alternative of explicitly prohibiting them in
> the proposal though.
>

I would strongly urge you to propose explicitly prohibiting them just as
UAX #31 recommends. Their reasoning is that these characters, which include
those that reverse text direction or control joining, can cause one
identifier to be maliciously changed to look like another. If you ignore
these characters instead of prohibiting them, an identifier that visually
appears as one string could in fact be a different one to the compiler.

Moreover, a compiler error can be made helpful by saying that the offending
character is potentially invisible and it can come with a fix-it to remove
the offending character. I don't think that would confuse the user at all.
It would be more confusing if invisible characters that caused one thing to
look identical to another were silently permitted.


> Sincerely,
> João Pinheiro
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[Anton Zhilin via swift-evolution]

L. Mihalkovic via swift-evolution  writes:

> Has a meta-circular syntax been considered for the precedence group 
definitions? Aside from limiting the
> proliferation of new keywords, it would also make them discoverable by 
reflection when the api gets added
> in 4.0. My apologies if it was already discarded.
> Regards
> LM

Could you please explain what you mean by "meta-circular syntax for the 
precedence group definitions"? An example?

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

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Slava Pestov via swift-evolution]

Great to hear some feedback so quickly, especially about something so mundane.

I suspect the real reason it doesn’t work this way now is that ‘Self’ is not 
fully plumbed through. In particular, if a closure captures the ‘Self’ type, 
IRGen does not properly codegen it, causing compile-time or run-time crashes:

class MyClass {
func foo(x: Int) -> Self {

// Crash!
_ = { print(self); print(x) }

return self
}

func bar(x: Int) -> MyClass {

// OK!
_ = { print(self); print(x) }

return self
}
}

Assertion failed: (LocalSelf && "no local self metadata"), function 
getLocalSelfMetadata, file /Users/slava/new/swift/lib/IRGen/GenType.cpp, line 
1805.
0  swift0x000114d5276e 
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 46
1  swift0x000114d52c99 
PrintStackTraceSignalHandler(void*) + 25
2  swift0x000114d4efc9 llvm::sys::RunSignalHandlers() + 
425
3  swift0x000114d53312 SignalHandler(int) + 354
4  libsystem_platform.dylib 0x7fffc438a01a _sigtramp + 26
5  libsystem_platform.dylib 0x507ca710 _sigtramp + 2353268496
6  swift0x000114d52cbb raise + 27
7  swift0x000114d52d62 abort + 18
8  swift0x000114d52d4e __assert_rtn + 126
9  swift0x00010f6e8524 
swift::irgen::IRGenFunction::getLocalSelfMetadata() + 100

This comes up most frequently with the ‘weak self / strong self’ dance.

I’m going to fix this bug really soon, and it seems logical to deal with the 
language wart as well. We need the IRGen fix for SE-0086 as well in any case.

Slava

> On Jun 23, 2016, at 1:08 PM, Matthew Johnson  wrote:
> 
> +1.  I have not encountered this issue myself but it looks like something 
> that would cause a lot of head scratching if I had.  It is also something 
> that I am unlikely to remember immediately if I run into it in the future.  
> The current behavior appears broken to me.  It will be great to have it fixed.
> 
>> On Jun 23, 2016, at 2:53 PM, Slava Pestov via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Consistent formal type for 'self' in class methods
>> 
>> Proposal: SE- 
>> 
>> Author: Slava Pestov 
>> Status: Awaiting review
>> Review manager: TBD
>> 
>>  
>> Introduction
>> 
>> This proposal makes the self value behave consistently whether or not it is 
>> used from a method with a Self return type.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal 
>> 
>>  
>> Motivation
>> 
>> Right now, we exhibit inconsistent behavior when self is used as an argument 
>> to a generic function, violating the principle of least surprise.
>> 
>> Consider the following code:
>> 
>> class Base {
>>   @discardableResult
>>   func methodWithDynamicSelf() -> Self {
>> doSomething(self)
>> return self
>>   }
>> 
>>   func methodWithoutDynamicSelf() {
>> doSomething(self)
>>   }
>> }
>> 
>> class Derived : Base {}
>> 
>> func doSomething(_ t: T) {
>>   print(T.self)
>> }
>> 
>> Base().methodWithDynamicSelf()
>> Base().methodWithoutDynamicSelf()
>> 
>> Derived().methodWithDynamicSelf()
>> Derived().methodWithoutDynamicSelf()
>> Currently, it prints the following output:
>> 
>> Base
>> Base
>> Derived
>> Base
>> Note that there's no inconsistency when the method is called on the base 
>> class. When called on the derived class however, we see that in a method 
>> with a dynamic Self return type, the type of self is Derived, whereas in a 
>> method with any other return type, the type of self is Base.
>> 
>> 
>>  
>> Proposed
>>  solution
>> 
>> The proposal is to change the type of self to always be Self, which can be 
>> thought of as a special generic type parameter bound to the dynamic type of 
>> the instance.
>> 
>> With this proposal, the above code will instead produce the following:
>> 
>> Base
>> Base
>> Derived
>> Derived
>> Here, the type of self would always be Derived when called on an instance of 
>> the derived class.
>> 
>> Of course a more useful program could instead do something with the type 
>> parameter T, such as constraining it to a protocol or a class with a 
>> required initializer, and then using the type to construct a new instance of 
>> the class.
>> 
>> This also dovetails nicely with SE-0068 
>> 

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Matthew Johnson via swift-evolution]

+1.  I have not encountered this issue myself but it looks like something that 
would cause a lot of head scratching if I had.  It is also something that I am 
unlikely to remember immediately if I run into it in the future.  The current 
behavior appears broken to me.  It will be great to have it fixed.

> On Jun 23, 2016, at 2:53 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Consistent formal type for 'self' in class methods
> 
> Proposal: SE- 
> 
> Author: Slava Pestov 
> Status: Awaiting review
> Review manager: TBD
> 
>  
> Introduction
> 
> This proposal makes the self value behave consistently whether or not it is 
> used from a method with a Self return type.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> Right now, we exhibit inconsistent behavior when self is used as an argument 
> to a generic function, violating the principle of least surprise.
> 
> Consider the following code:
> 
> class Base {
>   @discardableResult
>   func methodWithDynamicSelf() -> Self {
> doSomething(self)
> return self
>   }
> 
>   func methodWithoutDynamicSelf() {
> doSomething(self)
>   }
> }
> 
> class Derived : Base {}
> 
> func doSomething(_ t: T) {
>   print(T.self)
> }
> 
> Base().methodWithDynamicSelf()
> Base().methodWithoutDynamicSelf()
> 
> Derived().methodWithDynamicSelf()
> Derived().methodWithoutDynamicSelf()
> Currently, it prints the following output:
> 
> Base
> Base
> Derived
> Base
> Note that there's no inconsistency when the method is called on the base 
> class. When called on the derived class however, we see that in a method with 
> a dynamic Self return type, the type of self is Derived, whereas in a method 
> with any other return type, the type of self is Base.
> 
> 
>  
> Proposed
>  solution
> 
> The proposal is to change the type of self to always be Self, which can be 
> thought of as a special generic type parameter bound to the dynamic type of 
> the instance.
> 
> With this proposal, the above code will instead produce the following:
> 
> Base
> Base
> Derived
> Derived
> Here, the type of self would always be Derived when called on an instance of 
> the derived class.
> 
> Of course a more useful program could instead do something with the type 
> parameter T, such as constraining it to a protocol or a class with a required 
> initializer, and then using the type to construct a new instance of the class.
> 
> This also dovetails nicely with SE-0068 
> .
> 
> Finally, it opens the door to generalizing dynamic Self, allowing it to 
> appear in covariant position within parameter types:
> 
> class ArtClass {
>   func paint(withBrush: (Self) -> ()) { ... }
> }
> This would allow a class to conform to a protocol with a requirement written 
> like the following, something that is currently not possible at all:
> 
> protocol OddProtocol {
>   func weaken((Self) -> (X) -> Y) -> (X) -> Y
> }
> 
>  
> Detailed
>  design
> 
> There's really not much more to say here. The code for typing self with a 
> dynamic Self is in place already, however enabling this change might expose 
> some new bugs we have not yet encountered, because currently, methods with 
> dynamic Self return type are relatively rare.
> 
> 
>  
> Impact
>  on existing code
> 
> This will have a small impact on existing code that uses a pattern similar to 
> the above.
> 
> 
>  
> Alternatives
>  considered
> 
> One alternative is to simply do nothing, but this makes the language less 
> consistent than it could be.
> 
> ___
> 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] [Draft] Rationalizing Sequence end-operation names

[Anton Zhilin via swift-evolution]

• Renaming all methods which operate on more than one element at the 
beginning/end to use "prefix" or "suffix", not "first" or "last"

+1

• Renaming `index(of:/where:)` to `earliestIndex(…)` and `first(where:)` 
to `earliest(where:)`

-1, because `index` is considered state-of-art. `first` does not exist in 
all languages, but `earliest` is used nowhere.

• Renaming the `drop` methods to use `removing`

+0.5, because drop functions came from functional languages, but 
removingPrefix is much more to-the-point than dropFirst.

• Redesigning `prefix(upTo:)`, `prefix(through:)` and `suffix(from:)` as 
subscripts with "partial" ranges, like `people[..https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Prohibit invisible characters in identifier names

[Josh Wisenbaker via swift-evolution]

> On Jun 23, 2016, at 3:54 PM, João Pinheiro via swift-evolution 
>  wrote:
> 
>> On 23 Jun 2016, at 20:43, Xiaodi Wu > > wrote:
>> That's cool, although my preferred solution would be more closely aligned 
>> with UAX #31: overtly disallow the glyphs in Table 4 (instead of ignoring 
>> them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX 
>> #31, then afterwards internally represent the identifier as its 
>> NFC-normalized string.
> 
> Explicitly disallowing them was my initial idea, but I think it would end up 
> being a confusing error for users to encounter. Ignoring the invisible 
> characters and leaving it up to a linter to remove them is less likely to 
> cause confusion for users.

Allowing invisibles has already resulted in being able to do things like this 
which is intensely confusing to say the very least. 



Josh




smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

[Anton Zhilin via swift-evolution]

I must note that this `where` does not belong to `case`.
Compare:

for case x? where x < 10 in y { ... }
for x in y where x < 10 { ... }

First syntax is standard and won't go away. Second syntax is for-in 
specific, and is considered inconsistent.

* What is your evaluation of the proposal?

+1, because it removes piece of grammar that is unprecedented in other 
languages and that few people use.

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

Yes.

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

Yes, especially with Swift 3!

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

N/A

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

Followed the thread.

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

Re: [swift-evolution] Prohibit invisible characters in identifier names

[João Pinheiro via swift-evolution]

> On 23 Jun 2016, at 20:43, Xiaodi Wu  wrote:
> That's cool, although my preferred solution would be more closely aligned 
> with UAX #31: overtly disallow the glyphs in Table 4 (instead of ignoring 
> them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX 
> #31, then afterwards internally represent the identifier as its 
> NFC-normalized string.

Explicitly disallowing them was my initial idea, but I think it would end up 
being a confusing error for users to encounter. Ignoring the invisible 
characters and leaving it up to a linter to remove them is less likely to cause 
confusion for users.

I'll be sure to describe the alternative of explicitly prohibiting them in the 
proposal though.

Sincerely,
João Pinheiro
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Slava Pestov via swift-evolution]

Consistent formal type for 'self' in class methods

Proposal: SE- 

Author: Slava Pestov 
Status: Awaiting review
Review manager: TBD

 
Introduction

This proposal makes the self value behave consistently whether or not it is 
used from a method with a Self return type.

Swift-evolution thread: Discussion thread topic for that proposal 

 
Motivation

Right now, we exhibit inconsistent behavior when self is used as an argument to 
a generic function, violating the principle of least surprise.

Consider the following code:

class Base {
  @discardableResult
  func methodWithDynamicSelf() -> Self {
doSomething(self)
return self
  }

  func methodWithoutDynamicSelf() {
doSomething(self)
  }
}

class Derived : Base {}

func doSomething(_ t: T) {
  print(T.self)
}

Base().methodWithDynamicSelf()
Base().methodWithoutDynamicSelf()

Derived().methodWithDynamicSelf()
Derived().methodWithoutDynamicSelf()
Currently, it prints the following output:

Base
Base
Derived
Base
Note that there's no inconsistency when the method is called on the base class. 
When called on the derived class however, we see that in a method with a 
dynamic Self return type, the type of self is Derived, whereas in a method with 
any other return type, the type of self is Base.


 
Proposed
 solution

The proposal is to change the type of self to always be Self, which can be 
thought of as a special generic type parameter bound to the dynamic type of the 
instance.

With this proposal, the above code will instead produce the following:

Base
Base
Derived
Derived
Here, the type of self would always be Derived when called on an instance of 
the derived class.

Of course a more useful program could instead do something with the type 
parameter T, such as constraining it to a protocol or a class with a required 
initializer, and then using the type to construct a new instance of the class.

This also dovetails nicely with SE-0068 
.

Finally, it opens the door to generalizing dynamic Self, allowing it to appear 
in covariant position within parameter types:

class ArtClass {
  func paint(withBrush: (Self) -> ()) { ... }
}
This would allow a class to conform to a protocol with a requirement written 
like the following, something that is currently not possible at all:

protocol OddProtocol {
  func weaken((Self) -> (X) -> Y) -> (X) -> Y
}

 
Detailed
 design

There's really not much more to say here. The code for typing self with a 
dynamic Self is in place already, however enabling this change might expose 
some new bugs we have not yet encountered, because currently, methods with 
dynamic Self return type are relatively rare.


 
Impact
 on existing code

This will have a small impact on existing code that uses a pattern similar to 
the above.


 
Alternatives
 considered

One alternative is to simply do nothing, but this makes the language less 
consistent than it could be.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0105: Removing Where Clauses from For-In Loops

[Scott James Remnant via swift-evolution]

A separate point I would make, aside from my previous long-winded comment about 
clarity, is that the “confusion of use” in this proposal has already been 
corrected by SE-0099 which has removed `where` clauses from optional-binding 
and case-conditions.

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

Re: [swift-evolution] Prohibit invisible characters in identifier names

[Xiaodi Wu via swift-evolution]

On Thu, Jun 23, 2016 at 2:29 PM, João Pinheiro 
wrote:

> > I think we're using terminology differently here. What you call
> "character normalization" is what I'm calling canonicalization. NFC is
> described in UAX #15 as "canonical decomposition followed by canonical
> composition" and I'm just using the word "canonicalization" because it's
> shorter. If Swift represents each identifier in an NFC-transformed form
> (what I call canonicalized), then I understand the identifier to be
> canonicalized. What is the distinction you're drawing here?
>
> There is a small difference between normalisation and canonicalisation,
> but it's mostly splitting hairs. They both ensure something is represented
> properly, but canonicalisation implies establishing a single base
> representation for something. Web addresses are a good example. Both
> http://www.apple.com and http://apple.com are valid normalised addresses,
> but only the former is the canonical address for the Apple website.
>
> > Just re-read UAX #31. I see two different issues here too--do these
> match up with what you're saying above?
> >
> > * Disallowing certain glyphs in identifiers. To do so, we can implement
> the recommendation to disallow all glyphs in UAX #31 Table 4, except ZWJ
> and ZWNJ in the specific scenarios outlined in section 2.3.
> >
> > * Internally, when comparing two identifiers A and B, compare NFC(A) and
> NFC(B) without modifying or otherwise restricting the actual user-facing
> code to contain only NFC-normalized strings. This would be the approach
> recommended in section 1.3.
>
> Yes, that's correct. The proposal would be to normalise the encoding via
> NFC and then canonicalise the identifiers by ignoring invisible characters
> except in the scenarios described in UAX #31


That's cool, although my preferred solution would be more closely aligned
with UAX #31: overtly disallow the glyphs in Table 4 (instead of ignoring
them) except in the specific scenarios for ZWJ and ZWNJ identified in UAX
#31, then afterwards internally represent the identifier as its
NFC-normalized string.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0105: Removing Where Clauses from For-In Loops

[Scott James Remnant via swift-evolution]

-1

An important goal in Swift is “clarity at the point of use,” it appears in the 
API Design Guidelines as one of the fundamentals, but also pervades the design 
of the Swift language itself.

I think that removing the `where` clause from Swift’s `for` loops will reduce 
clarity of intent for many programmers.

It may be that `for`/`where` and `for`/`guard`/`continue` express the same 
result for the compiler, but an identical compiled output does not necessarily 
equate to an identical intent on behalf of the programmer. I do not believe 
that it has ever been a Swift goal that “there is only way one way to do it.”

Please consider the following example code:

  for line in lines where !line.isEmpty() {
…
  }

The intent of this code is clear to the reader. A set of lines from a line is 
being iterated, and filtered such that the code within the loop is only 
operating on those that are not empty. This is a fairly common pattern when 
working with files, for example. It may be that the code within the loop would 
work perfectly well even in the case of empty lines, the programmer simply does 
not wish to consider them.

Filtered iteration is a common pattern throughout programming, other uses 
include things like iterating the set of “updated objects” in Core Data, etc.

Now consider the equivalent avoiding a `where` clause, and replacing it with 
`guard`:

  for line in lines {
guard !line.isEmpty() else { continue }
…
  }

To the compiler it is the same code, but to the programmer this may have a very 
different intent.

`guard` in Swift is _not_ simply a generic `unless` statement, the name was 
chosen very specifically and less harsh names rejected. `guard` belongs closer 
to the family of `assert` and `precondition` than it does to `if`. `guard` is 
used to provide an expression of pattern that *must* be true for the code 
following it to operate without error or other unintended side-effects. This is 
why the `else` block must, in some way, exit the containing scope of the 
`guard`.

In first example the code makes it clear, to me, that it is normal for the set 
of lines to contain non-empty, and empty lines. But in the second example, to 
me, the code makes it clear that non-empty lines are not expected in the set, 
and would cause the code to error if they were present; the code guards against 
this by stepping over them—following Postel’s Law.

My opinion would be that the correct way of preserving the intent of the first 
example would be either:

  for line in lines {
if !line.isEmpty() {
  …
}
  }

or:

  for line in lines.lazy.filter({ !$0.isEmpty() }) {
…
  }

The second case is particularly troubling here because it’s “hard to get right” 
from a performance point of view. The clarity of `for`/`where` wins over all of 
these.

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

Re: [swift-evolution] Shorthand unwrap proposal

[David Sweeris via swift-evolution]

Dmitri pointed out a few posts ago that Swift already has this.
let opInt: Int? = nil
opInt.map {$0.toIntMax()} //Evaluates to nil

Are you talking about something different?

- Dave Sweeris

> On Jun 23, 2016, at 2:04 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> Sure, the exact syntax is a matter of discussion, I just wasn't that much of 
> favor of the very short
> 
> doSomething(with: myOptional?)
> 
> - it looks like a great idea, making the code really short
> - on the other hand the question mark is next to the variable, but the 
> method's execution is optional - in that sense something like doSomething(?: 
> myOptional)(with: myOptional) makes more sense, declaring explicitely what 
> optionals does the execution depend on.
> - nevertheless, in the interest of clarity and readability of the code, I'm 
> still in favor of the original proposal, which requires you to either use if 
> or guard.
> 
>> On Jun 23, 2016, at 8:57 PM, Tim Vermeulen  wrote:
>> 
>> But ! still suggests force unwrapping, while ? suggests safe unwrapping. Why 
>> not use a question mark?
>> 
>>> It was in the previous proposal and suggested that you are not trying to 
>>> shadow the previous variable, but trying to unwrap it - and it acts as 
>>> unwrapped from there on.
>>> 
>>> 
 On Jun 23, 2016, at 8:52 PM, Tim Vermeulenwrote:
 
 Why with the exclamation mark? It suggests you’re force unwrapping 
 something.
 
>> On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via 
>> swift-evolutionwrote:
>> 
>> I would love to be able to do something like
>> 
>> doSomething(with: myOptional?)
> This actually looks good to me, though if I were a newcomer to the 
> language, it would be really cryptic.
> 
> In case the function returned any value, it could become an optional, 
> just like with try?...
> 
> I still, however, prefer the original proposal of if let myOptional! { 
> doSomething(myOptional) }...
> 
>> 
>> which would be equivalent to
>> 
>> if let myValue = myOptional {
>> doSomething(with: myValue)
>> }
>> 
>> But it’s been discussed here before, and I don’t think people were very 
>> enthusiastic about it.
>> 
>>> I was wondering if people would be open to adding an unwrap method to 
>>> the Optional type,I already have a method like this which shortens code 
>>> for me.
>>> 
>>> So this:
>>> 
>>> let myReallyLongOptionalName: String? = "Hey"
>>> 
>>> if let string = myReallyLongOptionalName {
>>> doSomethingWith(string)
>>> }
>>> 
>>> Could become"
>>> 
>>> let myReallyLongOptionalName: String? = "Hey"
>>> 
>>> myReallyLongOptionalName.unwrap {
>>> doSomethingWith($0)
>>> }
>>> 
>>> The block would only be fired if myReallyLongOptionalName has a value.
>>> 
>>> 
>>> ___
>>> 
>>> 
>>> James⎥Head of Trolls
>>> 
>>> 
>>> ja...@supmenow.com(mailto:ja...@supmenow.com)⎥supmenow.com(http://supmenow.com)
>>> 
>>> 
>>> Sup
>>> 
>>> 
>>> Runway East
>>> 
>>> 
>>> 10 Finsbury Square
>>> 
>>> 
>>> London
>>> 
>>> 
>>> EC2A 1AF
>> ___
>> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Prohibit invisible characters in identifier names

[João Pinheiro via swift-evolution]

> I think we're using terminology differently here. What you call "character 
> normalization" is what I'm calling canonicalization. NFC is described in UAX 
> #15 as "canonical decomposition followed by canonical composition" and I'm 
> just using the word "canonicalization" because it's shorter. If Swift 
> represents each identifier in an NFC-transformed form (what I call 
> canonicalized), then I understand the identifier to be canonicalized. What is 
> the distinction you're drawing here?

There is a small difference between normalisation and canonicalisation, but 
it's mostly splitting hairs. They both ensure something is represented 
properly, but canonicalisation implies establishing a single base 
representation for something. Web addresses are a good example. Both 
http://www.apple.com and http://apple.com are valid normalised addresses, but 
only the former is the canonical address for the Apple website.

> Just re-read UAX #31. I see two different issues here too--do these match up 
> with what you're saying above?
> 
> * Disallowing certain glyphs in identifiers. To do so, we can implement the 
> recommendation to disallow all glyphs in UAX #31 Table 4, except ZWJ and ZWNJ 
> in the specific scenarios outlined in section 2.3.
> 
> * Internally, when comparing two identifiers A and B, compare NFC(A) and 
> NFC(B) without modifying or otherwise restricting the actual user-facing code 
> to contain only NFC-normalized strings. This would be the approach 
> recommended in section 1.3.

Yes, that's correct. The proposal would be to normalise the encoding via NFC 
and then canonicalise the identifiers by ignoring invisible characters except 
in the scenarios described in UAX #31.

Sincerely,
João Pinheiro
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0105: Removing Where Clauses from For-In Loops

[Kevin Ballard via swift-evolution]

>   * What is your evaluation of the proposal?
 
-1. I don't think this is really a big deal, but I find where clauses on
for loops to be very elegant, and I'm not convinced by any of the
arguments for why they should go away.
 
I'm especially not convinced by the argument over the behavior itself
being confusing, e.g. the fact that it's equivalent to a continue rather
than a break. You know what else is equivalent to a continue that this
proposal isn't modifying? `for case pattern in`. If the refutable
pattern does not match, the element is skipped and the for loop
continues to the next. This is precisely how the `where` clause works
(and it's no surprise that the two were introduced at the same time). So
the argument that says we should remove `where` in favor of explicit guard-
continues also implies that we should remove `for case pattern in`,
which I would strongly disagree with.
 
>   * Is the problem being addressed significant enough to warrant a
> change to Swift?
 
I don't think so. As the proposal argues, this feature is not very widely-
used, at least within open-source code (though as others have pointed
out, there's no data on how much it's used in closed-source code, and
it's plausible that there is far more closed-source Swift code than open-
source). Since it's not widely-used in public, the arguments for
removing it aren't very significant. And the people who do use it tend
to like the feature. And I agree with the people who have pointed out
that it's not the Swift compiler's job to enforce a single coding style.
 
> * How much effort did you put into your review? A glance, a quick
>   reading, or an in-depth study?
 
Reading the proposal and this review thread.
 
On Thu, Jun 23, 2016, at 10:25 AM, Erica Sadun via swift-evolution wrote:
>
>> On Jun 23, 2016, at 7:42 AM, Ryan Lovelett via swift-evolution > evolut...@swift.org> wrote:
>>> Is the problem being addressed significant enough to warrant a
>>> change to Swift?
>>
>> No. In fact, I think that even the proposal itself says as much. The
>> proposal indicates it means to deprecate an available coding
>> style. It
>> seems to me, as much as is practicable, style changes should be
>> enforced
>> by something other than the Swift compiler.
>>
>
> I in no way intended the proposal to "say as much".
>
> As syntactic sugar, the filtering syntax is
>  * rarely used in published deployed code,
 
With no info on how often it's used in closed-source code. Just
looking at a single closed-source project (the Postmates app), we use
the where clause on for loops 7 times, which is more than your
proposal says the stdlib and a random sampling of open source projects
uses combined. And this is just one project, so who knows how much
it's used in other projects.
 
>  * hard to discover (although I like others have taught it to promote
>its visibility),
 
If there's an educational issue here, that should be addressed in the
documentation (i.e. the book), rather than by removing the feature.
 
>  * elevates one style (continue if false) above others (continue if
>false, break if true, break if false), which are not expressible
>using similar shorthand,
 
I completely disagree. Removing this feature is elevating one style (guard-
continue) over another. Keeping the feature is not making any judgement
call about style whatsoever. And as I said above, `for case pattern in`
already has the continue-if-unmatched behavior, so removing this feature
does not mean the for loop no longer has a way to assume continue.
 
>  * introduces a fluent style that discourages design comments at the
>point of use,
 
You can comment where clauses. Just put it on a new line.
 
>  * can be difficult to breakpoint during debugging.
 
This can be said about a lot of things. If I want to breakpoint my where
clause, I can convert it to a guard-continue. Although first I'd try
putting the clause on its own line and seeing if lldb is smart enough to
then break just on the where clause.
 
> I think these are significant issues.
>
> The recommended alternative (using a separate guard) addresses all
> these points: better commenting, better breakpointing and debugging,
> and fully covers the domain of filtering and early exiting. If
> chaining is desired, using filter and prefix(while:) address all
> conditions, allow better commenting, etc, and are more self-
> documenting.
 
You can already use a separate guard. The existence of the where clause
on a for loop does not in any way detract from the ability to use a
separate guard.
 
>> On Jun 23, 2016, at 9:07 AM, Tony Allevato via swift-evolution > evolut...@swift.org> wrote:
>> The fact that some users may be confused by this terminology is not a
>> reason to remove it from the language. Some users will be confused by
>> many concepts in programming languages. If that means this is
>> considered an "advanced" feature, so be it. We should be able to have
>> a language that has both basic features and ad

Re: [swift-evolution] Shorthand unwrap proposal

[Tim Vermeulen via swift-evolution]

I wasn’t suggesting we allow the use of optional values as function parameters 
and just do nothing if the parameter is indeed optional. Optional parameters 
can be perfectly valid. I was talking about a syntax where we can put ? behind 
an optional parameter to signify that we don’t want to execute the function in 
case that particular parameter turns out to be nil, and we want the function to 
return nil if it has a return value.

> Regards(Frommobile)
> 
> On Jun 23, 2016, at 8:51 PM, Charlie Monroe via 
> swift-evolutionmailto:swift-evolution@swift.org)>wrote:
> 
> > 
> > > On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via 
> > > swift-evolutionmailto:swift-evolution@swift.org)>wrote:
> > > 
> > > I would love to be able to do something like
> > > 
> > > doSomething(with: myOptional?)
> > 
> > This actually looks good to me, though if I were a newcomer to the 
> > language, it would be really cryptic.
> > 
> > In case the function returned any value, it could become an optional, just 
> > like with try?...
> > 
> > I still, however, prefer the original proposal of if let myOptional! { 
> > doSomething(myOptional) }...
> > 
> func doSomething(with: t:T?, h:T->()) {
> iflett = self as?T{ h(t) }
> }
> extension Optional {
> 
> 
> funcunwrap(_h:T->()) {
> 
> iflett = self as?T{ h(t) }
> }
> 
> 
> }
> 
> Var s2:Sting?
> s2.unwrap{ (str:String)in
> print(":)")
> }
> 
> 
> doSomething(with:s2) { //same as above}
> 
> Nothing happens in both cases
> 
> > > 
> > > which would be equivalent to
> > > 
> > > if let myValue = myOptional {
> > > doSomething(with: myValue)
> > > }
> > > 
> > > But it’s been discussed here before, and I don’t think people were very 
> > > enthusiastic about it.
> > > 
> > > > I was wondering if people would be open to adding an unwrap method to 
> > > > the Optional type,I already have a method like this which shortens code 
> > > > for me.
> > > > 
> > > > So this:
> > > > 
> > > > let myReallyLongOptionalName: String? = "Hey"
> > > > 
> > > > if let string = myReallyLongOptionalName {
> > > > doSomethingWith(string)
> > > > }
> > > > 
> > > > Could become"
> > > > 
> > > > let myReallyLongOptionalName: String? = "Hey"
> > > > 
> > > > myReallyLongOptionalName.unwrap {
> > > > doSomethingWith($0)
> > > > }
> > > > 
> > > > The block would only be fired if myReallyLongOptionalName has a value.
> > > > 
> > > > 
> > > > ___
> > > > 
> > > > 
> > > > James⎥Head of Trolls
> > > > 
> > > > 
> > > > ja...@supmenow.com(mailto:ja...@supmenow.com)(mailto:ja...@supmenow.com)⎥supmenow.com(http://supmenow.com)(http://supmenow.com)
> > > > 
> > > > 
> > > > Sup
> > > > 
> > > > 
> > > > Runway East
> > > > 
> > > > 
> > > > 10 Finsbury Square
> > > > 
> > > > 
> > > > London
> > > > 
> > > > 
> > > > EC2A 1AF
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > 
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto: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] [Review] SE-0104: Protocol-oriented integers

[Max Moiseev via swift-evolution]

Hi Remy,

> I would also like to know why bit shifting and bit-wise and, or and xor 
> operations are limited to FixedWidthInteger. I would think that a 
> variable-length integer would be able to handle these operations in a 
> predictable way consistent with the protocol. Wouldn't it?

The problem is that with fixed-width, the values will eventually "fall off the 
cliff” when shifted left, but with the arbitrary-precision integers we can 
simply grow the underlying storage so that “the cliff” is never reached.

Which means that in generic context, when all you have is some T that conforms 
to Integer, you won’t be able to tell what will happen exactly.

Pretty much the same argument applies to the bitwise operations: since 2 
bignums might have different widths of the underlying storage, the semantics of 
those operations is not exactly the same as for the fixed width types. Does it 
make sense?


Max

> On Jun 23, 2016, at 9:08 AM, Remy Demarest via swift-evolution 
>  wrote:
> 
> I would also like to know why bit shifting and bit-wise and, or and xor 
> operations are limited to FixedWidthInteger. I would think that a 
> variable-length integer would be able to handle these operations in a 
> predictable way consistent with the protocol. Wouldn't it?
> 
>> Le 22 juin 2016 à 23:23, Félix Cloutier via swift-evolution 
>>  a écrit :
>> 
>> Do we lose the ability to create a signed integer from an unsigned bit 
>> pattern?
>> 
>> Is there a way to get an optional initializer that returns `nil` if the 
>> operand can't be represented?
>> 
>> What is the cost of heterogeneous comparison?
>> 
>> Félix
>> 
>>> Le 22 juin 2016 à 22:42:00, David Waite via swift-evolution 
>>>  a écrit :
>>> 
>>> In addition to the technical review, I would like to point out that the 
>>> definition of Arithmetic appears to be missing some underscores in 
>>> add/adding/subtract/subtracting
 

 https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
 
* What is your evaluation of the proposal?
>>> 
>>> I’m so glad this work is being done!
>>> 
>>> For Integer, does the presence of signBit indicate an expectation that 
>>> signed Integers will have a two's complement representation?
>>> 
>>> For FixedWidthInteger#dividedWithOverflow/remainderWithOverflow, under what 
>>> situations would you have an overflow? I could only come up with something 
>>> like Int.min.dividedWithOverflow(-1).
>>> 
* Is the problem being addressed significant enough to warrant a change 
 to Swift?
>>> 
>>> Yes, oh yes.
>>> 
* Does this proposal fit well with the feel and direction of Swift?
>>> 
>>> It looks like a significant improvement. 
>>> 
 
* How much effort did you put into your review? A glance, a quick 
 reading, or an in-depth study?
>>> 
>>> I combed the proposal for questions, although most were answered by the 
>>> time I hit the end.
>>> 
>>> -DW
>>> 
>>> ___
>>> 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
> 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] Shorthand unwrap proposal

[Charlie Monroe via swift-evolution]

Sure, the exact syntax is a matter of discussion, I just wasn't that much of 
favor of the very short

doSomething(with: myOptional?)

- it looks like a great idea, making the code really short
- on the other hand the question mark is next to the variable, but the method's 
execution is optional - in that sense something like doSomething(?: 
myOptional)(with: myOptional) makes more sense, declaring explicitely what 
optionals does the execution depend on.
- nevertheless, in the interest of clarity and readability of the code, I'm 
still in favor of the original proposal, which requires you to either use if or 
guard.

> On Jun 23, 2016, at 8:57 PM, Tim Vermeulen  wrote:
> 
> But ! still suggests force unwrapping, while ? suggests safe unwrapping. Why 
> not use a question mark?
> 
>> It was in the previous proposal and suggested that you are not trying to 
>> shadow the previous variable, but trying to unwrap it - and it acts as 
>> unwrapped from there on.
>> 
>> 
>>> On Jun 23, 2016, at 8:52 PM, Tim Vermeulenwrote:
>>> 
>>> Why with the exclamation mark? It suggests you’re force unwrapping 
>>> something.
>>> 
> On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via 
> swift-evolutionwrote:
> 
> I would love to be able to do something like
> 
> doSomething(with: myOptional?)
 This actually looks good to me, though if I were a newcomer to the 
 language, it would be really cryptic.
 
 In case the function returned any value, it could become an optional, just 
 like with try?...
 
 I still, however, prefer the original proposal of if let myOptional! { 
 doSomething(myOptional) }...
 
> 
> which would be equivalent to
> 
> if let myValue = myOptional {
> doSomething(with: myValue)
> }
> 
> But it’s been discussed here before, and I don’t think people were very 
> enthusiastic about it.
> 
>> I was wondering if people would be open to adding an unwrap method to 
>> the Optional type,I already have a method like this which shortens code 
>> for me.
>> 
>> So this:
>> 
>> let myReallyLongOptionalName: String? = "Hey"
>> 
>> if let string = myReallyLongOptionalName {
>> doSomethingWith(string)
>> }
>> 
>> Could become"
>> 
>> let myReallyLongOptionalName: String? = "Hey"
>> 
>> myReallyLongOptionalName.unwrap {
>> doSomethingWith($0)
>> }
>> 
>> The block would only be fired if myReallyLongOptionalName has a value.
>> 
>> 
>> ___
>> 
>> 
>> James⎥Head of Trolls
>> 
>> 
>> ja...@supmenow.com(mailto:ja...@supmenow.com)⎥supmenow.com(http://supmenow.com)
>> 
>> 
>> Sup
>> 
>> 
>> Runway East
>> 
>> 
>> 10 Finsbury Square
>> 
>> 
>> London
>> 
>> 
>> EC2A 1AF
> ___
> 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] Shorthand unwrap proposal

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 23, 2016, at 8:51 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> 
>> On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via swift-evolution 
>>  wrote:
>> 
>> I would love to be able to do something like
>> 
>> doSomething(with: myOptional?)
> 
> This actually looks good to me, though if I were a newcomer to the language, 
> it would be really cryptic.
> 
> In case the function returned any value, it could become an optional, just 
> like with try?...
> 
> I still, however, prefer the original proposal of if let myOptional! { 
> doSomething(myOptional) }...
> 

func doSomething (with: t:T?, h: T -> ()) {
if let t = self as? T { h(t) }
}
extension Optional {
func unwrap (_ h: T -> ()) {
if let t = self as? T { h(t) }
}
}

Var s2:Sting? 
s2.unwrap { (str:String) in
print(":)") 
}
doSomething(with:s2) { //same as above}

Nothing happens in both cases

>> 
>> which would be equivalent to
>> 
>> if let myValue = myOptional {
>>   doSomething(with: myValue)
>> }
>> 
>> But it’s been discussed here before, and I don’t think people were very 
>> enthusiastic about it.
>> 
>>> I was wondering if people would be open to adding an unwrap method to the 
>>> Optional type,I already have a method like this which shortens code for me.
>>> 
>>> So this:
>>> 
>>> let myReallyLongOptionalName: String? = "Hey"
>>> 
>>> if let string = myReallyLongOptionalName {
>>> doSomethingWith(string)
>>> }
>>> 
>>> Could become"
>>> 
>>> let myReallyLongOptionalName: String? = "Hey"
>>> 
>>> myReallyLongOptionalName.unwrap {
>>> doSomethingWith($0)
>>> }
>>> 
>>> The block would only be fired if myReallyLongOptionalName has a value.
>>> 
>>> 
>>> ___
>>> 
>>> 
>>> James⎥Head of Trolls
>>> 
>>> 
>>> ja...@supmenow.com(mailto:ja...@supmenow.com)⎥supmenow.com(http://supmenow.com)
>>> 
>>> 
>>> Sup
>>> 
>>> 
>>> Runway East
>>> 
>>> 
>>> 10 Finsbury Square
>>> 
>>> 
>>> London
>>> 
>>> 
>>> EC2A 1AF
>> ___
>> 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
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Shorthand unwrap proposal

[Tim Vermeulen via swift-evolution]

But ! still suggests force unwrapping, while ? suggests safe unwrapping. Why 
not use a question mark?

> It was in the previous proposal and suggested that you are not trying to 
> shadow the previous variable, but trying to unwrap it - and it acts as 
> unwrapped from there on.
> 
> 
> > On Jun 23, 2016, at 8:52 PM, Tim Vermeulenwrote:
> > 
> > Why with the exclamation mark? It suggests you’re force unwrapping 
> > something.
> > 
> > > > On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via 
> > > > swift-evolutionwrote:
> > > > 
> > > > I would love to be able to do something like
> > > > 
> > > > doSomething(with: myOptional?)
> > > This actually looks good to me, though if I were a newcomer to the 
> > > language, it would be really cryptic.
> > > 
> > > In case the function returned any value, it could become an optional, 
> > > just like with try?...
> > > 
> > > I still, however, prefer the original proposal of if let myOptional! { 
> > > doSomething(myOptional) }...
> > > 
> > > > 
> > > > which would be equivalent to
> > > > 
> > > > if let myValue = myOptional {
> > > > doSomething(with: myValue)
> > > > }
> > > > 
> > > > But it’s been discussed here before, and I don’t think people were very 
> > > > enthusiastic about it.
> > > > 
> > > > > I was wondering if people would be open to adding an unwrap method to 
> > > > > the Optional type,I already have a method like this which shortens 
> > > > > code for me.
> > > > > 
> > > > > So this:
> > > > > 
> > > > > let myReallyLongOptionalName: String? = "Hey"
> > > > > 
> > > > > if let string = myReallyLongOptionalName {
> > > > > doSomethingWith(string)
> > > > > }
> > > > > 
> > > > > Could become"
> > > > > 
> > > > > let myReallyLongOptionalName: String? = "Hey"
> > > > > 
> > > > > myReallyLongOptionalName.unwrap {
> > > > > doSomethingWith($0)
> > > > > }
> > > > > 
> > > > > The block would only be fired if myReallyLongOptionalName has a value.
> > > > > 
> > > > > 
> > > > > ___
> > > > > 
> > > > > 
> > > > > James⎥Head of Trolls
> > > > > 
> > > > > 
> > > > > ja...@supmenow.com(mailto:ja...@supmenow.com)⎥supmenow.com(http://supmenow.com)
> > > > > 
> > > > > 
> > > > > Sup
> > > > > 
> > > > > 
> > > > > Runway East
> > > > > 
> > > > > 
> > > > > 10 Finsbury Square
> > > > > 
> > > > > 
> > > > > London
> > > > > 
> > > > > 
> > > > > EC2A 1AF
> > > > ___
> > > > 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