Re: [swift-evolution] Variadic generics discussion

[L. Mihalkovic via swift-evolution]

On Jun 1, 2016, at 3:29 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> There's definitely the possibility of going off the deep end with complexity 
>> like C++, but since we already have tuples as a primitive language feature, 
>> I think there's a straightforward language design that enables the most 
>> important use cases for variadics. If we have "tuple splatting" for argument 
>> forwarding, and some support for iterating tuples, like we briefly discussed 
>> in the context of (4 x Int) fixed-sized homogeneous tuples, that'd probably 
>> be enough.
> 
> I read the original proposal, started writing up a response along these 
> lines, and then scrolled up to see what others had said. I'm glad you agree!
> 
> Here's my sketch.
> 
> * * *
> 
> In general, my preferred direction for this feature would tie variadics 
> closely to tuples, and variadic types closely to tuple types. To wit:
> 
> 1. We should dust off the old tuple indexing proposal (I actually forgot it 
> was never reviewed) and get it through, along with tuple `count`, `map`, and 
> probably a few other Collection-like operations which generate fixed 
> signatures. (I'm going to use a method-style syntax, but a #function-style 
> syntax would work too; we could even introduce a .#method-style syntax.)

Sounds like more compiler magic... rather than trying to reduce it.


> 
>let tuple: (Int, Int, Int, Int) = (2, 4, 6, 8)
>print(tuple[tuple.0])// => 6
>print(tuple.map { $0 / 2 })// => (1, 2, 3, 4)
> 
> 2. We should allow you to use analogous operators on the type of a tuple, too.
> 
>let value: (Int, String)[1] = "Hello, world!"
>(Int, String).map { $0.Type }// => (Int.Type, String.Type)
> 
> 3. We should change our existing variadic parameters to create tuples, not 
> Arrays.
> 
>func print(_ items: (Any...), separator: String = "", terminator: String = 
> "\n") {
>items.0// Yes, that's a thing you can do
> 
> 4. We should add a splat operator which unpacks tuples into (possibly 
> variadic) parameters.
> 
>print(tuple...)
> 
> 5. We should allow you to define variadic type parameters.
> 
>// Note: If you had written `items: Items` instead of `items: Items...`, 
> it would've taken a tuple 
>// of various LocalizedStringConvertible types.
>func localizedPrint(_ items: 
> Items..., separator: String = "", terminator: String = "\n") {
>print(items.map { $0.localizedDescription }, separator: separator, 
> terminator: terminator)
>}
> 
> 6. We should extend splat to unpack tuple types into (possibly variadic) type 
> parameters.
> 
>typealias Pair = (String, Int)
>let table: Dictionary = [:]
> 
> (7. Optional pet-peeve fixer, which I will not actually demonstrate: Require 
> unconstrained type parameters to be spelled `T: Any`, not just `T`. This will 
> remove an asymmetry, in that a variable-length tuple of any type has to be 
> spelled `T: (Any...)`, but a single parameter is just spelled `T`.)
> 
> What do we end up with here?
> 
> Zip:
> 
>struct ZipSequence: Sequence {
>typealias Iterator: ZipIterator
>
>var sequences: Sequences
>
>func makeIterator() -> ZipIterator {
>return ZipIterator.init(sequences.map { $0.makeIterator() }...)
>}
>
>init(_ sequences: Sequences...) {
>self.sequences = sequences
>}
>}
>
>struct ZipIterator: IteratorProtocol {
>typealias Element = Iterators.map { $0.Element }
>
>var iterators: Iterators
>
>init(_ iterators: Iterators...) {
>self.iterators = iterators
>}
>
>mutating func next() -> Element? {
>// Note: It may be too difficult to assign a type to this 
> reduction;
>// something like the proposal's `#invert` may thus be necessary.
>// If it is added, I would hope that an analogous operation would 
>// be added to `Sequence`s of `Optional`s.
>let nextValues = iterators.map { $0.next() }.reduce(Optional( () 
> )) { earlier, this in
>guard let earlier = earlier, this = this else {
>return nil
>}
>return earlier + (this)
>}
>guard let nextValues = nextValues else {
>return nil
>}
>return nextValues
>}
>}
> 
> Function application is basically just a use of the splat feature:
> 
>// Note that the `args: Args` here is *not* `...`ed, so it takes a tuple.
>// Meanwhile, the `Args` in `(Args...) -> Result` does have `...`, so it's 
> looking 
>// for arguments which that tuple could be splatted into.
>func apply(_ args: Args, to function: (Args...) -> 
> Return) -> Return {
>return function(args...)
>}
>
>func method(_ name: 

Re: [swift-evolution] [Pitch] Expose assert configuration functions in standard library

[Brent Royal-Gordon via swift-evolution]

> My pitch: I want to promote these three helper functions to the standard 
> library and remove their underscore prefixes.

These functions currently have implementations like this:

@_transparent
@warn_unused_result
public // @testable
func _isDebugAssertConfiguration() -> Bool {
  // The values for the assert_configuration call are:
  // 0: Debug
  // 1: Release
  // 2: Fast
  return Int32(Builtin.assert_configuration()) == 0
}

I think how this works is:

* @_transparent makes sure these functions are always inlined at the call site.
* Most things in the standard library are *also* @_transparent.
* Therefore, after both (or more!) inlinings happen, you get the 
`Builtin.assert_configuration()` of the code calling into the standard library.

Needless to say, this is *extremely* weird and magical, and I'm skeptical of 
the idea that we should expose it as a normal function call.

I think a better design which would accurately convey its magic is to add a 
type to the standard library:

enum BuildKind: Int32 { case debug, release, unchecked }

(Note: the names in this could use some bikeshedding. Put that aside.)

And then add a `#buildKind` compiler substitution which is equivalent to:

BuildKind(rawValue: Int32(Builtin.assert_configuration()))

Now you can surround your debug-only code with `#buildKind == .debug`. Or you 
can capture the *call site's* build kind with a default parameter:

func log(_ message: String, level: LogLevel = .info, buildKind: 
BuildKind = #buildKind)

Even the standard library might be able to do this if it wanted to, allowing 
your code to enable or disable asserts based on whether your caller's code is 
in debug mode or not:

func assert(@autoclosure condition: () -> Bool, @autoclosure _ message: 
() -> String = default, file: StaticString= #file, line: UInt = #line, 
buildKind: BuildKind = #buildKind)

(I wouldn't suggest that every stdlib member add such a default parameter; most 
should continue to rely on `@_transparent`. But I think that could be useful 
for calls like `assert()` and `precondition()`.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal] Shorthand Argument Renaming

[Thorsten Seitz via swift-evolution]

> Am 31.05.2016 um 10:14 schrieb Chris Williams via swift-evolution 
> :
> 
> Honestly what I’ve wanted for quite some time is just reasonable default 
> parameter names. $0/$1… or any variation on index-based arguments is terrible 
> for comprehension, and I feel like I’m being lazy and hurting whoever has to 
> look at the code next every time I type out something like say  String]?.map { $0 } instead of .map{ key, value in key }.

So, just write the latter.

> If the Dictionary type’s map function could define “key” and “value” as 
> parameter types it would go a long way in terms or readability, in my opinion.

The map function does not impose names on the arguments of the literal closure. 
You can choose them freely.

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

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Thorsten Seitz via swift-evolution]

+1

`return` in guards should stay, because there one has to use either `return`, 
`continue` or `break`. It would be ugly and inconsistent if one of these could 
be left out.

-Thorsten 

> Am 31.05.2016 um 20:16 schrieb Vladimir.S via swift-evolution 
> :
> 
> I really like the proposal in case of properties and functions, but I really 
> don't want to have
> guard boolean else { "false" }
> 
> I feel like `return` is very important part of `guard` statement.
> I understand the requirement for consistency with 
> properties/closures/functions, but I'll prefer to have some inconsistency in 
> language in this case and require `return` for `guard`. And in case I'll have 
> to choose all-or-nothig, I'll give -1 for the proposal.
> 
> I.e. IMO current `return` in properties and functions is less evil than 
> absent of `return` in `guard`.
> 
>> On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:
>> Here is the draft proposal:
>> https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md
>> 
>> Did I covered everything case? If you find some mistakes feel free to
>> provide feedback so I can fix the proposal before I submit a PR.
>> 
>> 
>> 
>> --
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution
>> (swift-evolution@swift.org ) schrieb:
>> 
>>> +1
>>> 
>>> L
>>> 
>>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution
>>>  wrote:
>>> >
>>> >> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution 
>>> >>  wrote:
>>> >>
>>> >> It isn’t a special case because all other single-statement closures in 
>>> >> the language work that way. It’s actually inconsistent now.
>>> >
>>> > Computed properties aren’t closures so it’s not inconsistent in that 
>>> > sense.  But it is inconsistent in that closures are the *only* 
>>> > value-returning code blocks that are able to use this sugar.  It would be 
>>> > nice to see this sugar consistently allowed everywhere in the language.
>>> >
>>> >>
>>> >>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution 
>>> >>>  wrote:
>>> >>>
>>> >>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution 
>>> >>>  wrote:
>>> >>>
>>>  The idea is simple:
>>> 
>>>  • Can we make return keyword optional in cases like this?
>>>  • Shouldn’t this behave like @autoclosure or @noescape?
>>>  type A {
>>>    var characters: [Character] = …
>>>    var string: String { String(self.characters) }
>>>    var count: Int { 42 }
>>>  }
>>> 
>>>  Is this worth a proposal or Swifty enough, what do you think?
>>> 
>>>  Sure I could write return, but why do we allow this behavior for 
>>>  @noescape functions like map!?
>>> >>>
>>> >>> While I am not necessarily against this idea, I do wonder if it’s worth 
>>> >>> making what’s going on here less obvious simply for the sake of being 
>>> >>> able to omit a six character keyword. As I understand it, one of the 
>>> >>> reasons ++/-- were removed was due to the increased "burden to learn 
>>> >>> Swift as a first programming language.” This is the sort of thing that 
>>> >>> becomes another one of those special cases that has to be explained to 
>>> >>> someone new to Swift.
>>> >>>
>>> >>> /brian
>>> >>>
>>> >>> ___
>>> >>> 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
>> 
>> 
>> 
>> ___
>> 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] [Pre-proposal] Forward/Reverse Only Indexing Methods

[Thorsten Seitz via swift-evolution]

I like this idea. The problem is that it would require that we have an 
Index.NonNegativeDistance as argument to really make it statically safe. And we 
would have to have methods producing these, probably as optional return values.
Otherwise we won't have achieved statically safety but effectively just better 
documentation about the capabilities of the respective collection.

-Thorsten 


> Am 31.05.2016 um 14:46 schrieb Haravikk via swift-evolution 
> :
> 
> So for Swift 3 we’re going to have the great new indexing model that performs 
> index manipulation through the collection to which an index belongs.
> 
> However, it retains one of the things I didn’t like about the old model, 
> which is that the distinction between forward/backward only types is a bit 
> fuzzy, since the single advancedBy() method, now the index(:offsetBy:) 
> method, was used for both forward and backward movement, which seems 
> contradictory compared to the forward/backward only single-step methods.
> 
> Anyway, I’m wondering what people’s thoughts would be on tweaking the formula 
> slightly such that there are methods that only work in a particular 
> direction, i.e- we’d have three main variations of the methods like so:
> 
> public func index(_ index:Index, advancedBy:Index.Distance) -> Index { … 
> } // Available on forward and bidirectional collections
> public func index(_ index:Index, reversedBy:Index.Distance) -> Index { … 
> } // Available on reverse and bidirectional collections
> public func index(_ index:Index, offsetBy:Index.Distance) -> Index { … } 
> // Available only on bidirectional collections
> 
> (note, the naming isn’t definite, as reversed may not be clear enough, it’s 
> just an example for now)
> 
> There are three reasons I’d prefer this:
> 
> The first is that I can pass the same distance into either of the first two 
> methods, and any negation etc. is handled internally. In essence I shouldn’t 
> have to handle negative distances at all when working with the first two 
> methods. So if I’m working with a step size of 5, I can just pass that into 
> the appropriate method, I never have to do anything with it the value itself.
> 
> The second benefit is that there should be no uncertainty about the 
> capabilities of the type you’re using; if it doesn’t have the 
> index(:reversedBy:) method then you can’t go backwards, same as 
> index(before:) and index(after:).
> 
> The third and main benefit is that the methods are just more explicit about 
> what they do, and what direction you can go in; passing negatives into either 
> of the first two would produce errors outright, allowing you to pick on 
> mistakes in these cases.
> 
> The other main thing is that offsetBy doesn’t indicate whether a type 
> supports forward-only offsets, you have to read the documentation to 
> determine this either in the method itself or the type, whereas the presence 
> or absence of the first two variants are pretty clear.
> 
> Currently the offsetBy, and the previous advancedBy(), methods require 
> forward-only types to produce fatal errors if handed a negative distance, and 
> vice versa for backward-only types, which can only produce errors at runtime, 
> whereas the presence or absence of the first two methods can be handled 
> during development. You could still pass a negative value and end up with a 
> runtime error instead of course, but for the types of common uses they’re 
> intended for you should be unlikely to produce one.
> 
> The offsetBy form would still exist for bidirectional collections, but would 
> only really be used when you need to do more complex index/distance 
> manipulation outside of the type where a calculation might produce either 
> positive or negative values (e.g- if you're calculating the distance and 
> don’t know where two indices are in relation to each other), the rest of the 
> time you should try to use the more specific, single-direction forms as they 
> clarify your intent and can help to catch mistakes if you’ve incorrectly 
> generated a distance for example.
> 
> 
> Just curious what other people’s thoughts are about this?
> 
> I intended to mention this a lot sooner (to change advancedBy), but then I 
> find out about the new indexing model so thought I’d wait until afterwards, 
> then completely forgot =)
> ___
> 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-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Thorsten Seitz via swift-evolution]

Great! Thanks for the additional details!

-Thorsten 

> Am 31.05.2016 um 19:31 schrieb John McCall :
> 
>> On May 29, 2016, at 6:38 AM, Thorsten Seitz  wrote:
>> An, now I see what you mean. You are right, P ::= ∃ t : P . t is a 
>> constrained existential type defining a subtype relationship.
>> Thanks for enlightening me!
>> 
>> I haven’t perceived a protocol as an existential up to now, probably because 
>> my understanding has come from Haskell where subtyping does not exists and 
>> where therefore a hidden unbound type parameter plays a central role (see 
>> definitions below) which has made me believe that an associated type is 
>> necessary. But for simple protocols this role is indeed taken by the 
>> conforming type. The difference is that this is equivalent to subtyping 
>> whereas associated types (as another form of hidden unbound type parameters) 
>> are not, resulting in two kinds of protocols.
>> Is there another terminology to distinguish between those two kinds?
> 
> It's not a standard restriction or really even a necessary one.  It's an 
> artifact of earlier implementations of both the type-checker and the runtime 
> representation of protocol conformances.
> 
> RE: the type-checker, it used to be the case that calls on existentials were 
> awkward special cases: the type-checker didn't actually "open" the 
> existential as a rigid type variable, it just magically ignored self and 
> patched things together later.  That's a type-checking strategy that's 
> extremely prone to soundness bugs, so a harsh restriction is required.  
> Fortunately, it's also a type-checking strategy we've abandoned, although 
> there's still work to be done to build associated types correctly for opened 
> existentials.
> 
> RE: the runtime representation, it used to be the case that you couldn't 
> recover associated type information at runtime from a protocol conformance 
> and so it had to be passed separately; that could have been supported in the 
> existential representation as well, but we knew we wanted to change that 
> about protocol conformances, and we didn't want to introduce a great deal of 
> complexity for an unnecessary intermediate position.
> 
> So I wouldn't sweat trying to formally describe the current situation, 
> because it's a "temporary" implementation limitation.
> 
> John.
> 
> 
>> 
>> -Thorsten
>> 
>> 
>> "Existential types, or 'existentials' for short, are a way of 'squashing' a 
>> group of types into one, single type. […] 
>> data T = forall a. MkT a“ 
>> (https://en.wikibooks.org/wiki/Haskell/Existentially_quantified_types)
>> 
>> "Existential quantification hides a type variable within a data constructor.“
>> (https://prime.haskell.org/wiki/ExistentialQuantification)
>> 
>> "For example, the type "T = ∃X { a: X; f: (X → int); }" describes a module 
>> interface that has a data member named a of type X and a function named f 
>> that takes a parameter of the same type X and returns an integer. […] Given 
>> a value "t" of type "T", we know that "t.f(t.a)" is well-typed, regardless 
>> of what the abstract type X is. This gives flexibility for choosing types 
>> suited to a particular implementation while clients that use only values of 
>> the interface type—the existential type—are isolated from these choices.“
>> (https://en.wikipedia.org/wiki/Type_system#Existential_types)
>> 
>> 
>> 
 Am 27.05.2016 um 19:36 schrieb John McCall :
 
 On May 25, 2016, at 7:07 AM, Thorsten Seitz via swift-evolution 
  wrote:
 This is unfortunate, because then the meaning of "existential" and 
 "non-existential" in Swift are just the opposite of their respective 
 meaning in standard terminology :-(
>>> 
>>> I don't know what you mean by this.  The standard terminology is that an 
>>> existential type is one that's directly existentially-quantified, e.g. ∃ t 
>>> . t, which is essentially what a Swift protocol type is:
>>>   P ::= ∃ t : P . t
>>>   P.Type ::= ∃ t : P . t.Type
>>> etc.  Language operations then implicitly form (erasure) and break down 
>>> (opening) those qualifiers in basically the same way that they implicitly 
>>> break down the universal quantifiers on generic functions.
>>> 
>>> If you're thinking about Haskell, Haskell's existential features are 
>>> carefully tied to constructors and pattern-matching in part because erasure 
>>> is a kind of implicit conversion, which would not fit cleanly into 
>>> Haskell's type system.  (Universal application also requires an implicit 
>>> representation change, but that doesn't need to be reflected in H-M systems 
>>> for technical reasons unless you're trying to support higher-rank 
>>> polymorphism; I'm not up on the type-checking literature there.)
>>> 
>>> John.
>>> 
>>> 
 
 -Thorsten
 
 
 Am 25. Mai 2016 um 14:27 schrieb Brent Royal-Gordon 
 :
 
>> AFAIK an 

Re: [swift-evolution] Ad hoc enums / options

[Austin Zheng via swift-evolution]

I admire the desire of this proposal to increase the readability of code.
I'm -1 to the proposal itself, though:

- It breaks the ability to pass in a variable containing the desired value,
rather than the literal value itself. (Unless you actually want a
not-so-anonymous enum type whose definition happens to live in a function
signature rather than somewhere you'd usually expect a type definition to
live.)
- It breaks the ability to store a reference to the function in a variable
of function type (ditto).
- Almost every time I've wanted to use one of these "anonymous enums" in my
code, I've ended up needing to use that same enum elsewhere. In my
experience, 'lightweight enums' don't end up saving much time compared to a
full-fledged one.

Like Brent said, I have to say no to any proposal that tries to make enums
synonyms for numerical values. What happens if you rearrange your anonymous
enum cases between library versions? Do you somehow store an opaque
case-to-UInt8 table somewhere for every anonymous enum you define for
resilience? What happens when people start bringing back terrible C
patterns, like doing arithmetic or bitwise ops on the underlying case
values? At least you have to try pretty hard as it is to abuse Swift's
enums.

Austin

On Tue, May 31, 2016 at 8:25 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > And the obvious answer is you can have up to 255 of these babies for the
> anonymous enum type, and be able to pass numerical equivalents UInt8 with
> compile time substitution. That the ad-hoc enumeration is basically a
> syntactic shorthand for UInt8, with an enforced upper bound compile time
> check simplifies everything including switch statements.
>
> If I wanted a language like that, I'd be writing C, not Swift.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> 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] Variadic generics discussion

[Brent Royal-Gordon via swift-evolution]

> I agree that this is a better design for Swift than the monstrosity I started 
> out with.
> 
> The "biggest" technical challenge I see is being able to type a reduction 
> sort of operator on a heterogenous tuple based on on whatever protocols and 
> constraints are common to its constituent members. For example:
> 
> // Every Tn in T... is Fooable and Barrable
> let x : (T...)
> reduce(x, reducer, startingValue)
> 
> func reducer(startingValue: U, eachMemberOfT: X) -> U { ... }
> 
> How do we bound ??? such that 'reducer' is useful while still being 
> statically type sound? Honestly, that's the most interesting question to me. 
> Generalized existentials might help with that.

You know, I'm not a big fan of the `&` syntax people are pushing in the `Any<>` 
thread, but if you ignore the Ceylon people begging for union types, I think a 
sensible alternative meaning for `|` would be "all common supertypes of these 
types". Then you could write:

// Bottom here is the bottom type: the subtype of all types.
(Int, String, Bool).reduce(Bottom, combine: |)

And you'll end up with something like:

Equatable & Hashable & _Reflectable

Which are the three protocols all of those types support. If they'd supported 
no common protocols, it would've ended up with `Any`. (Interestingly, this is 
arguably the same operation which should be used to determine the return value 
of tuple subscripting.)

Of course, nothing about having this feature *requires* that we use `&` and 
`|`; that was just the inspiration for it.

> Other questions (inherent to any proposal) would be:
> 
> - How do we resolve the impedance mismatch between tuples and function 
> argument lists? Is it even worth trying to resolve this mismatch, given that 
> argument lists are intentionally not intended to mirror tuples?

As far as I know, tuples support a subset of argument list features. (For 
instance, they don't support default values.) So if you splat a tuple into a 
parameter list, the worst case is that you won't get to use features like those.

One mismatch is that tuples barely care about their argument labels, while 
parameter lists select overloads on them. My temptation would be to require you 
to disambiguate with `(x:y:z)` syntax if you were splatting in an unclear way.

let triple = (0, 10, 2)

stride(triple...)   // Illegal due to ambiguity; write one 
of these:
stride(from:to:by:)(triple...)
stride(from:through:by:)(triple...)

One useful thing here is that the arity and types of a tuple are known at 
compile time, so we can figure out ahead of time how to interpret the call. 
That wouldn't be the case if you could splat arrays.

(Incidentally, we might want to offer a pseudo-failable initializer to create a 
tuple from a sequence:

if let triple = (Int, Int, Int)(intArray) {
return stride(from:to:by:)(triple...)
}

That would indirectly allow you to splat the contents of an array into a 
parameter list.)

> - As you said, how do variadic generics work in the 0- and 1-member cases?

I don't think 0-tuples are a big deal, except in that there's no good starting 
value for certain reductions. Adding a bottom type (as I did in the `reduce` 
example above) would fix that.

1-tuples are a bigger problem, because if you have a parameter like `(Any...)`, 
you can't afford to interpret `((Int, String))` as `(Int, String)`. It might be 
possible to support 1-tuples only in contexts where you're using a variadic 
tuple, but I'm kind of skeptical of that idea.

Personally, I wish we'd just acknowledge `(SomeType)` (or maybe `(SomeType, )`) 
as something different from `SomeType` and stop fretting. Sure, it's a 
semi-useless degenerate case, but so are one-case `enum`s and 
`Optional`s, and we don't ban those. Banning `T -> U` syntax has already 
removed one of the sources of ambiguity here.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Ad hoc enums / options

[Brent Royal-Gordon via swift-evolution]

> And the obvious answer is you can have up to 255 of these babies for the 
> anonymous enum type, and be able to pass numerical equivalents UInt8 with 
> compile time substitution. That the ad-hoc enumeration is basically a 
> syntactic shorthand for UInt8, with an enforced upper bound compile time 
> check simplifies everything including switch statements.

If I wanted a language like that, I'd be writing C, not Swift.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Working with enums by name

[Brent Royal-Gordon via swift-evolution]

> Don't you think it's a bit of a waste to be repeating the name of the value 
> as a string just to use init(rawValue:) with them?

Who said anything about repeating the name?

Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). Type 
:help for assistance.
  1> enum Planet: String { case mercury, venus, earth, mars, jupiter, saturn, 
uranus, neptune }
  2> Planet.mercury.rawValue
$R0: String = "mercury"

> What if I need to store another string associated with the value of the enum 
> e.g. I want to create an enum to represent options in a menu and the 
> associated value is to be the name of the image file to be used for that 
> option?

Use the instance as a key into a dictionary of images. (Or use the rawValue as 
a key into a plist dictionary of image names. Or just name the image after the 
rawValue.)

In any case, this sounds like we're back to your other thread, the one about 
attaching properties to cases. That's a great feature, but it's a different 
feature from this one.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

[Joe Groff via swift-evolution]

> On May 31, 2016, at 5:54 PM, Chris Lattner  wrote:
> 
>> On May 31, 2016, at 6:20 PM, Joe Groff  wrote:
>>> If the goal was to remove magic from the compiler, then a possible 
>>> direction would be to do something like:
>>> 
>>> 1) Introduce a new declmodifier named something like “atomiclazy”.
>>> 2) Disallow global and static variables, unless they are explicitly marked 
>>> atomiclazy (compiler would provide a fixit hint to suggest this).
>>> 3) Replace the atomiclazy magic with a property behavior when they exist.
>> 
>> This doesn't make sense. This "magic" is the only sensible way to initialize 
>> a global that requires dynamic initialization. Even with property behaviors, 
>> we would need to lazily apply the behavior's initialization logic to get the 
>> property into its initial state. Nonatomic lazy would be a 
>> misoptimization—it's hard to beat dispatch_once at its own game.
> 
> Why couldn’t a "sufficiently advanced" property behavior provide the same 
> static initialization guarantees (e.g. its initialization is statically 
> known) for its stored property, and then use dispatch_once as its 
> implementation?  The compiler doesn’t know anything magic here.

There's quite a bit of magic about global initialization—it knows it can hoist 
and fold initialization checks, and how to turn effectively constant 
initializations into static initializations and avoid the laziness altogether. 
dispatch_once furthermore only works for global initializations, since its 
token is magic and must be statically initialized to zero at process start. 
Since our existing global initialization implementation only works for globals, 
and does the right thing for 99% of globals, this seems like foolish 
generalization to me, punishing the common case and opening opportunity for 
user mistakes for no gain.

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

Re: [swift-evolution] Variadic generics discussion

[Austin Zheng via swift-evolution]

I agree that this is a better design for Swift than the monstrosity I
started out with.

The "biggest" technical challenge I see is being able to type a reduction
sort of operator on a heterogenous tuple based on on whatever protocols and
constraints are common to its constituent members. For example:

// Every Tn in T... is Fooable and Barrable
let x : (T...)
reduce(x, reducer, startingValue)

func reducer(startingValue: U, eachMemberOfT: X) -> U { ... }

How do we bound ??? such that 'reducer' is useful while still being
statically type sound? Honestly, that's the most interesting question to
me. Generalized existentials might help with that.

Other questions (inherent to any proposal) would be:

- How do we resolve the impedance mismatch between tuples and function
argument lists? Is it even worth trying to resolve this mismatch, given
that argument lists are intentionally not intended to mirror tuples?

- As you said, how do variadic generics work in the 0- and 1-member cases?

I definitely agree that tuples are a inherently variadic, inherently
generic, sufficiently primitive data structure to map well onto the concept.

Austin




On Tue, May 31, 2016 at 6:29 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> > There's definitely the possibility of going off the deep end with
> complexity like C++, but since we already have tuples as a primitive
> language feature, I think there's a straightforward language design that
> enables the most important use cases for variadics. If we have "tuple
> splatting" for argument forwarding, and some support for iterating tuples,
> like we briefly discussed in the context of (4 x Int) fixed-sized
> homogeneous tuples, that'd probably be enough.
>
> I read the original proposal, started writing up a response along these
> lines, and then scrolled up to see what others had said. I'm glad you agree!
>
> Here's my sketch.
>
> * * *
>
> In general, my preferred direction for this feature would tie variadics
> closely to tuples, and variadic types closely to tuple types. To wit:
>
> 1. We should dust off the old tuple indexing proposal (I actually forgot
> it was never reviewed) and get it through, along with tuple `count`, `map`,
> and probably a few other Collection-like operations which generate fixed
> signatures. (I'm going to use a method-style syntax, but a #function-style
> syntax would work too; we could even introduce a .#method-style syntax.)
>
> let tuple: (Int, Int, Int, Int) = (2, 4, 6, 8)
> print(tuple[tuple.0])   // => 6
> print(tuple.map { $0 / 2 }) // => (1, 2, 3, 4)
>
> 2. We should allow you to use analogous operators on the type of a tuple,
> too.
>
> let value: (Int, String)[1] = "Hello, world!"
> (Int, String).map { $0.Type }   // => (Int.Type,
> String.Type)
>
> 3. We should change our existing variadic parameters to create tuples, not
> Arrays.
>
> func print(_ items: (Any...), separator: String = "", terminator:
> String = "\n") {
> items.0 // Yes, that's a thing you can do
>
> 4. We should add a splat operator which unpacks tuples into (possibly
> variadic) parameters.
>
> print(tuple...)
>
> 5. We should allow you to define variadic type parameters.
>
> // Note: If you had written `items: Items` instead of `items:
> Items...`, it would've taken a tuple
> // of various LocalizedStringConvertible types.
> func localizedPrint(_
> items: Items..., separator: String = "", terminator: String = "\n") {
> print(items.map { $0.localizedDescription }, separator:
> separator, terminator: terminator)
> }
>
> 6. We should extend splat to unpack tuple types into (possibly variadic)
> type parameters.
>
> typealias Pair = (String, Int)
> let table: Dictionary = [:]
>
> (7. Optional pet-peeve fixer, which I will not actually demonstrate:
> Require unconstrained type parameters to be spelled `T: Any`, not just `T`.
> This will remove an asymmetry, in that a variable-length tuple of any type
> has to be spelled `T: (Any...)`, but a single parameter is just spelled
> `T`.)
>
> What do we end up with here?
>
> Zip:
>
> struct ZipSequence: Sequence {
> typealias Iterator: ZipIterator $0.Iterator }...>
>
> var sequences: Sequences
>
> func makeIterator() -> ZipIterator {
> return ZipIterator.init(sequences.map {
> $0.makeIterator() }...)
> }
>
> init(_ sequences: Sequences...) {
> self.sequences = sequences
> }
> }
>
> struct ZipIterator:
> IteratorProtocol {
> typealias Element = Iterators.map { $0.Element }
>
> var iterators: Iterators
>
> init(_ iterators: Iterators...) {
> self.iterators = iterators
> }
>
>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Xiaodi Wu via swift-evolution]

Revisiting this conversation, it seems that most of the design space has
been thoroughly explored. I think all suggestions presented so far boil
down to these:

Q: How is an arbitrary boolean assertion introduced after `if let`?

Option 1 (present scenario)--using `where`
Advantages: expressive when it means exactly the right thing
Drawbacks: makes obligatory the suggestion of a semantic relationship
between what comes before and after even when there is no such relationship

Option 2--using a symbol sometimes encountered in conditional statements
(e.g. `&&` or comma)
Advantages: doesn't look out of place
Drawbacks: needs to be disambiguated from existing uses, necessitating
other changes in syntax

Option 3--using a symbol never encountered in conditional statements (e.g.
semicolon)
Advantages: doesn't need to be disambiguated from any existing uses
Drawbacks: looks out of place

For me, options 1 and 2 have permanent and objective drawbacks. By
contrast, familiarity increases with time, and beauty is in the eye of the
beholder.

* * *

It does occur to me that there is one more option. I don't know that I like
it, but it's an option no one has put forward before: recite the opening
keyword when beginning a new boolean expression:

`if let x = x where x < 3 { ... }` becomes
`if let x = x if x < 3 { ... }`

`while let item = sequence.next() where item > 0 { ... }` becomes
`while let item = sequence.next() while item > 0 { ... }`

etc.


On Tue, May 31, 2016 at 2:00 PM, Erica Sadun  wrote:

>
> > On May 31, 2016, at 12:52 PM, Xiaodi Wu  wrote:
> > These lines of reasoning are what have compelled me to conclude that
> `where` might not be salvageable.
>
> To which, I'd add: `where` suggests there's a subordinate and semantic
> relationship between the primary condition and the clause. There's no way
> as far as I know this to enforce it in the grammar and the proposal allows
> both clauses to be stated even without the connecting word. You could make
> a vague argument, I suppose, for renaming `where` to `when` but all in all,
> even killing `where` we benefit with better expressive capabilities and a
> simpler grammar.
>
> -- E
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Working with enums by name

[Leonardo Pessoa via swift-evolution]

If I got the idea right, you would need to implement yourself the protocol 
methods to answer for both init(rawValue: Int) and init(rawValue: String) - 
which is how you have to do today only with the string part - while my proposed 
approach you'd have to implement nothing yourself.

L

> On 31 May 2016, at 7:19 pm, Austin Zheng via swift-evolution 
>  wrote:
> 
> If we had generic protocols, you could implement RawRepresentable twice, once 
> using Ints and one using Strings. But that's probably never going to happen.
> 
> /digression
> 
> Austin
> 
>> On Tue, May 31, 2016 at 3:11 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> > On May 31, 2016, at 4:07 PM, Brent Royal-Gordon via swift-evolution 
>> >  wrote:
>> >
>> >> • also wants OptionSetType-like behavior (and thus an Int raw type).
>> >
>> > Then it's not an `enum`, it's a `struct`.
>> 
>> You can get it for free as an array of enums and test with contains vs member
>> 
>> -- E, who has probably digressed more than she really should
>> ___
>> 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] Variadic generics discussion

[Brent Royal-Gordon via swift-evolution]

> There's definitely the possibility of going off the deep end with complexity 
> like C++, but since we already have tuples as a primitive language feature, I 
> think there's a straightforward language design that enables the most 
> important use cases for variadics. If we have "tuple splatting" for argument 
> forwarding, and some support for iterating tuples, like we briefly discussed 
> in the context of (4 x Int) fixed-sized homogeneous tuples, that'd probably 
> be enough.

I read the original proposal, started writing up a response along these lines, 
and then scrolled up to see what others had said. I'm glad you agree!

Here's my sketch.

* * *

In general, my preferred direction for this feature would tie variadics closely 
to tuples, and variadic types closely to tuple types. To wit:

1. We should dust off the old tuple indexing proposal (I actually forgot it was 
never reviewed) and get it through, along with tuple `count`, `map`, and 
probably a few other Collection-like operations which generate fixed 
signatures. (I'm going to use a method-style syntax, but a #function-style 
syntax would work too; we could even introduce a .#method-style syntax.)

let tuple: (Int, Int, Int, Int) = (2, 4, 6, 8)
print(tuple[tuple.0])   // => 6
print(tuple.map { $0 / 2 }) // => (1, 2, 3, 4)

2. We should allow you to use analogous operators on the type of a tuple, too.

let value: (Int, String)[1] = "Hello, world!"
(Int, String).map { $0.Type }   // => (Int.Type, String.Type)

3. We should change our existing variadic parameters to create tuples, not 
Arrays.

func print(_ items: (Any...), separator: String = "", terminator: 
String = "\n") {
items.0 // Yes, that's a thing you can do

4. We should add a splat operator which unpacks tuples into (possibly variadic) 
parameters.

print(tuple...)

5. We should allow you to define variadic type parameters.

// Note: If you had written `items: Items` instead of `items: 
Items...`, it would've taken a tuple 
// of various LocalizedStringConvertible types.
func localizedPrint(_ items: 
Items..., separator: String = "", terminator: String = "\n") {
print(items.map { $0.localizedDescription }, separator: 
separator, terminator: terminator)
}

6. We should extend splat to unpack tuple types into (possibly variadic) type 
parameters.

typealias Pair = (String, Int)
let table: Dictionary = [:]

(7. Optional pet-peeve fixer, which I will not actually demonstrate: Require 
unconstrained type parameters to be spelled `T: Any`, not just `T`. This will 
remove an asymmetry, in that a variable-length tuple of any type has to be 
spelled `T: (Any...)`, but a single parameter is just spelled `T`.)

What do we end up with here?

Zip:

struct ZipSequence: Sequence {
typealias Iterator: ZipIterator

var sequences: Sequences

func makeIterator() -> ZipIterator {
return ZipIterator.init(sequences.map { 
$0.makeIterator() }...)
}

init(_ sequences: Sequences...) {
self.sequences = sequences
}
}

struct ZipIterator: IteratorProtocol {
typealias Element = Iterators.map { $0.Element }

var iterators: Iterators

init(_ iterators: Iterators...) {
self.iterators = iterators
}

mutating func next() -> Element? {
// Note: It may be too difficult to assign a type to 
this reduction;
// something like the proposal's `#invert` may thus be 
necessary.
// If it is added, I would hope that an analogous 
operation would 
// be added to `Sequence`s of `Optional`s.
let nextValues = iterators.map { $0.next() 
}.reduce(Optional( () )) { earlier, this in
guard let earlier = earlier, this = this else {
return nil
}
return earlier + (this)
}
guard let nextValues = nextValues else {
return nil
}
return nextValues
}
}

Function application is basically just a use of the splat feature:

// Note that the `args: Args` here is *not* `...`ed, so it takes a 
tuple.
// Meanwhile, the `Args` in `(Args...) -> Result` does have `...`, so 
it's looking 
// for arguments which that tuple could be splatted into.
func apply(_ args: Args, to function: (Args...) 

Re: [swift-evolution] Working with enums by name

[Leonardo Pessoa via swift-evolution]

Don't you think it's a bit of a waste to be repeating the name of the value as 
a string just to use init(rawValue:) with them? What if I need to store another 
string associated with the value of the enum e.g. I want to create an enum to 
represent options in a menu and the associated value is to be the name of the 
image file to be used for that option? I don't know how common that is, but I 
don't see how good it is for you to keep repeating yourself in your code when 
the value you want and need is right by your side (DRY principle) and can be 
used easily in one way (to string) but not the other (back to enum).

L

On 31 May 2016, at 6:48 pm, Brent Royal-Gordon  wrote:

>> |   enum Planet : Int {
>> |  case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
>> |
>> |  init?(caseName name : String) {
> 
> The compiler actually does this already through RawRepresentable if you put 
> `String` as your raw type. So what's the use case for this? Code which needs 
> both a non-String rawValue *and* needs to look up cases by name? How common 
> do you think that is?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Variadic generics discussion

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 31, 2016, at 7:10 PM, Chris Lattner  wrote:
> 
> This is very close to my priority list.  That said, I think that all of these 
> are out of scope for swift 3 sadly.  

Happy to hear these priorities look about right to you also.  (I realized 
afterwards that I left off opening existentials which I would put around 5 or 6)

BTW, generalized existentials is #2 for me if we include things that already 
have proposals as well.  That going to be a game changer.

I've already been assuming we won't see any major new generics features in 
Swift 3.  

> 
> After Swift 3, the priority list will be driven by what the standard library 
> needs to get its APIs realized in their ideal form (eg without any of the _ 
> protocol hacks).  Conditional conformances certainly top the list, but we 
> will have to carefully and ruthlessly prioritize things in order to get to 
> ABI stability.

Makes sense.

> 
> -Chris
> 
>> On May 31, 2016, at 2:16 PM, Matthew Johnson  wrote:
>> 
>> 
>>> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution 
>>>  wrote:
>>> 
>>> This is pretty much where my thinking about the topic has led me as well. 
>>> I'll resign this topic to pursue some other, hopefully more relevant work, 
>>> although anyone who wants to continue the discussion is welcome to.
>> 
>> Seems reasonable to wait until we can at least evaluate the macro approach 
>> properly.
>> 
>> Are you planning to continue work on generics?  FWIW, my top priority list 
>> for items without proposals is roughly:
>> 
>> 1. Conditional conformance 
>> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-)
>> 2. Parameterized extensions 
>> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions)
>> 3. Generic subscripts 
>> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts)
>> 4. Recursive protocol constraints 
>> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics)
>> 5. Nested generics 
>> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics)
>> 6. Default generic arguments 
>> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-generic-arguments)
>> 7. Extensions of structural types 
>> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types)
>> 
>> And this one seems like low hanging fruit:
>> 
>> Default implementations in protocols 
>> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols-)
>> 
>> How does this compare to your priorities for generics?
>> 
>>> 
 On Tue, May 31, 2016 at 12:49 PM, Chris Lattner  wrote:
 
> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution 
>  wrote:
> 
> well there is no macro system, and for the moment a clear statement from 
> chris that this is not on the table in the short term. the code in the 
> example looked like run-of-the-mill swift, except for the “…". so that 
> leaves us with swift looking code that would be executed by the compiler, 
> but with nothing particular to tell which parts to and which not. just a 
> thought.
 
 Lets be clear though: variadic generics are not in scope for Swift 3 
 either.  
 
 I definitely don’t speak for the rest of the core team, nor have I 
 discussed it with them…  but IMO, this whole feature seems like a better 
 fit for a macro system than it does to complicate the generics system.  
 Unlike C++’s template system, our generics system inherently has runtime / 
 dynamic dispatch properties, and I don’t think that shoehorning variadics 
 into it is going to work out well.
 
 -Chris
 
> 
> 
>> On May 31, 2016, at 7:59 PM, Austin Zheng  wrote:
>> 
>> How so? I'm interested in anything that can get us away from having to 
>> generating code at compile-time.
>> 
>> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic 
>>  wrote:
>>> 
>>> What's interesting about the code in the manifesto is that it looks 
>>> very much like "..." is a runtime construct, as opposed to trying the 
>>> get the compiler to do the heavy lifting.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

[Chris Lattner via swift-evolution]

> On May 31, 2016, at 6:20 PM, Joe Groff  wrote:
>> If the goal was to remove magic from the compiler, then a possible direction 
>> would be to do something like:
>> 
>> 1) Introduce a new declmodifier named something like “atomiclazy”.
>> 2) Disallow global and static variables, unless they are explicitly marked 
>> atomiclazy (compiler would provide a fixit hint to suggest this).
>> 3) Replace the atomiclazy magic with a property behavior when they exist.
> 
> This doesn't make sense. This "magic" is the only sensible way to initialize 
> a global that requires dynamic initialization. Even with property behaviors, 
> we would need to lazily apply the behavior's initialization logic to get the 
> property into its initial state. Nonatomic lazy would be a 
> misoptimization—it's hard to beat dispatch_once at its own game.

Why couldn’t a "sufficiently advanced" property behavior provide the same 
static initialization guarantees (e.g. its initialization is statically known) 
for its stored property, and then use dispatch_once as its implementation?  The 
compiler doesn’t know anything magic here.

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

Re: [swift-evolution] Variadic generics discussion

[Chris Lattner via swift-evolution]

> On May 31, 2016, at 6:05 PM, Joe Groff  wrote:
> 
> 
>> On May 31, 2016, at 12:49 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution 
>>>  wrote:
>>> 
>>> well there is no macro system, and for the moment a clear statement from 
>>> chris that this is not on the table in the short term. the code in the 
>>> example looked like run-of-the-mill swift, except for the “…". so that 
>>> leaves us with swift looking code that would be executed by the compiler, 
>>> but with nothing particular to tell which parts to and which not. just a 
>>> thought.
>> 
>> Lets be clear though: variadic generics are not in scope for Swift 3 either. 
>>  
>> 
>> I definitely don’t speak for the rest of the core team, nor have I discussed 
>> it with them…  but IMO, this whole feature seems like a better fit for a 
>> macro system than it does to complicate the generics system.  Unlike C++’s 
>> template system, our generics system inherently has runtime / dynamic 
>> dispatch properties, and I don’t think that shoehorning variadics into it is 
>> going to work out well.
> 
> There's definitely the possibility of going off the deep end with complexity 
> like C++, but since we already have tuples as a primitive language feature, I 
> think there's a straightforward language design that enables the most 
> important use cases for variadics. If we have "tuple splatting" for argument 
> forwarding, and some support for iterating tuples, like we briefly discussed 
> in the context of (4 x Int) fixed-sized homogeneous tuples, that'd probably 
> be enough.

Ok, fair enough.  However, I think that it is inescapable that any discussion 
of variadic generics needs to include implementation concerns.

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

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Chris Lattner via swift-evolution]

> On May 30, 2016, at 3:09 PM, Erica Sadun  wrote:
> You can't splat but you can decompose a tuple by assignment:

Right.  That is because assignment permits destructuring.  Parameter lists do 
not (anymore).

-Chris

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

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

[Joe Groff via swift-evolution]

> On May 31, 2016, at 12:37 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On May 31, 2016, at 6:32 AM, David Rönnqvist via swift-evolution 
>>  wrote:
>> Lazy evaluation when assigning static variables
>> 
>> Introduction
>> 
>> Both stored type properties (static) and lazy stored properties (lazy var) 
>> are lazily initialized. However, they have different initialization behavior 
>> in that stored type properties evaluate even when assigning them a new value.
>> 
>> The following code will print "static", but not "lazy":
>> 
>> class
>>  Foo {
>> 
>> static var bar: String =
>>  {
>> 
>> print("static"
>> )
>> 
>> return "Default"
>> 
>> }()
>> 
>> 
>> lazy var baz: String =
>>  {
>> 
>> print("lazy"
>> )
>> 
>> return "Lazy"
>> 
>> }()
>> }
>> 
>> Foo
>> .bar = "Set" // this evaluates the initial value of `bar` before setting a 
>> new value
>> 
>> 
>> 
>> let foo =
>>  Foo()
>> foo
>> .baz = "Set" // this doesn't evaluate `baz` before setting a new value
> This seems like a step in the right direction, but may not big a step far 
> enough.  Keep in mind that “static” and global variables are quite different 
> than lazy variables, both in terms of implementation and behavior but also in 
> terms of planned future direction.
> 
> “lazy” is almost certainly to be replaced by property behaviors in the 
> future, making them a library defined feature whose behavior can be changed 
> arbitrarily, and can hopefully have useful additional functionality like a 
> “reset()” method added to them.  Global variables are currently not like 
> that: their behavior is defined by compiler magic instead of by property 
> semantics.
> 
> If the goal was to remove magic from the compiler, then a possible direction 
> would be to do something like:
> 
> 1) Introduce a new declmodifier named something like “atomiclazy”.
> 2) Disallow global and static variables, unless they are explicitly marked 
> atomiclazy (compiler would provide a fixit hint to suggest this).
> 3) Replace the atomiclazy magic with a property behavior when they exist.

This doesn't make sense. This "magic" is the only sensible way to initialize a 
global that requires dynamic initialization. Even with property behaviors, we 
would need to lazily apply the behavior's initialization logic to get the 
property into its initial state. Nonatomic lazy would be a misoptimization—it's 
hard to beat dispatch_once at its own game.

-Joe

> In this model, you’d presumably have the choice about atomiclazy or lazy when 
> setting up either a static or a local property.
> 
> -Chris
> 
> 
> 
> ___
> 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] Variadic generics discussion

[Chris Lattner via swift-evolution]

This is very close to my priority list.  That said, I think that all of these 
are out of scope for swift 3 sadly.  

After Swift 3, the priority list will be driven by what the standard library 
needs to get its APIs realized in their ideal form (eg without any of the _ 
protocol hacks).  Conditional conformances certainly top the list, but we will 
have to carefully and ruthlessly prioritize things in order to get to ABI 
stability.

-Chris

> On May 31, 2016, at 2:16 PM, Matthew Johnson  wrote:
> 
> 
>> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> This is pretty much where my thinking about the topic has led me as well. 
>> I'll resign this topic to pursue some other, hopefully more relevant work, 
>> although anyone who wants to continue the discussion is welcome to.
> 
> Seems reasonable to wait until we can at least evaluate the macro approach 
> properly.
> 
> Are you planning to continue work on generics?  FWIW, my top priority list 
> for items without proposals is roughly:
> 
> 1. Conditional conformance 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-)
> 2. Parameterized extensions 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions)
> 3. Generic subscripts 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts)
> 4. Recursive protocol constraints 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics)
> 5. Nested generics 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics)
> 6. Default generic arguments 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-generic-arguments)
> 7. Extensions of structural types 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types)
> 
> And this one seems like low hanging fruit:
> 
> Default implementations in protocols 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols-)
> 
> How does this compare to your priorities for generics?
> 
>> 
>>> On Tue, May 31, 2016 at 12:49 PM, Chris Lattner  wrote:
>>> 
 On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution 
  wrote:
 
 well there is no macro system, and for the moment a clear statement from 
 chris that this is not on the table in the short term. the code in the 
 example looked like run-of-the-mill swift, except for the “…". so that 
 leaves us with swift looking code that would be executed by the compiler, 
 but with nothing particular to tell which parts to and which not. just a 
 thought.
>>> 
>>> Lets be clear though: variadic generics are not in scope for Swift 3 
>>> either.  
>>> 
>>> I definitely don’t speak for the rest of the core team, nor have I 
>>> discussed it with them…  but IMO, this whole feature seems like a better 
>>> fit for a macro system than it does to complicate the generics system.  
>>> Unlike C++’s template system, our generics system inherently has runtime / 
>>> dynamic dispatch properties, and I don’t think that shoehorning variadics 
>>> into it is going to work out well.
>>> 
>>> -Chris
>>> 
 
 
> On May 31, 2016, at 7:59 PM, Austin Zheng  wrote:
> 
> How so? I'm interested in anything that can get us away from having to 
> generating code at compile-time.
> 
> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic 
>  wrote:
>> 
>> What's interesting about the code in the manifesto is that it looks very 
>> much like "..." is a runtime construct, as opposed to trying the get the 
>> compiler to do the heavy lifting.
 
 ___
 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] Variadic generics discussion

[Joe Groff via swift-evolution]

> On May 31, 2016, at 12:49 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution 
>>  wrote:
>> 
>> well there is no macro system, and for the moment a clear statement from 
>> chris that this is not on the table in the short term. the code in the 
>> example looked like run-of-the-mill swift, except for the “…". so that 
>> leaves us with swift looking code that would be executed by the compiler, 
>> but with nothing particular to tell which parts to and which not. just a 
>> thought.
> 
> Lets be clear though: variadic generics are not in scope for Swift 3 either.  
> 
> I definitely don’t speak for the rest of the core team, nor have I discussed 
> it with them…  but IMO, this whole feature seems like a better fit for a 
> macro system than it does to complicate the generics system.  Unlike C++’s 
> template system, our generics system inherently has runtime / dynamic 
> dispatch properties, and I don’t think that shoehorning variadics into it is 
> going to work out well.

There's definitely the possibility of going off the deep end with complexity 
like C++, but since we already have tuples as a primitive language feature, I 
think there's a straightforward language design that enables the most important 
use cases for variadics. If we have "tuple splatting" for argument forwarding, 
and some support for iterating tuples, like we briefly discussed in the context 
of (4 x Int) fixed-sized homogeneous tuples, that'd probably be enough.

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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Hooman Mehr via swift-evolution]

This arises a different question: Should `description` always return the same 
value? For example: Can `description` of “May 31th, 2016” return “Today” if we 
evaluate it today and return “Yesterday” if we evaluate it tomorrow? Are such 
side-effects (using a volatile global value) permitted? Then how about 
localization? Can description be locale-aware without breaking the protocol? 

> On May 31, 2016, at 3:43 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> My original v2 proposal draft suggested making value preserving and human 
> readable descriptions orthogonal, but Chris and a few other people suggested 
> they liked the originally suggested design better. I have a link in the 
> "Alternatives" section to that original draft.
> 
> Austin
> 
> On Tue, May 31, 2016 at 3:22 PM, Dave Abrahams via swift-evolution 
> > wrote:
> 
> on Tue May 31 2016, Thorsten Seitz  > wrote:
> 
> > I agree with Vladimir. Having a value preserving representation is
> > orthogonal to a human readable representation.
> 
> I too think he's making a good point.  I could be missing something, but
> it seems to me we don't fully understand this design yet.
> 
> --
> Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Russ Bishop via swift-evolution]

>> On May 27, 2016, at 5:30 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> 
>>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon  
>>> wrote:
>>> 
 guard
 x == 0 && a == b && c == d &&
 let y = optional, w = optional2, v = optional 3 &&
 z == 2
 else { ... }
 
 Figuring out where to break the first line into expression and into 
 condition (after the `d`) could be very challenging to the compiler.
>>> 
>>> I'm not sure it is. `let` and `case` are not valid in an expression, so an 
>>> `&&` followed by `let` or `case` must be joining clauses. On the other side 
>>> of things, Swift's `&&` doesn't ever produce an optional, so if we're 
>>> parsing an expression at the top level of an if-let, an `&&` must indicate 
>>> the end of the clause. An if-case *could* theoretically include an `&&`, 
>>> but pattern matching against a boolean value seems like a fairly useless 
>>> thing to do in a context that's specifically intended to test booleans.
>> 
>> Let me answer in another way that speaks to my background which isn't in 
>> compiler theory: The use of && may produce cognitive overload between the 
>> use in Boolean assertions and the use in separating condition clauses.
>> 
>> -- E

In reality I often write if/guard statements using && exactly the way Brent 
proposes, only to go back and rework it for syntax correctness. I started this 
message intending to argue for Brent’s proposal but I think I’ve talked myself 
out of it :)


> On May 28, 2016, at 10:26 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> 
>> My suggestion would be to reuse our normal && operator:
>> 
>>  guard
>>  x == 0 &&
>>  let y = optional &&
>>  z == 2
>>  else { ... }
>> 
>> This would obviously be a built-in `&&` separate from our existing, infix 
>> operator `&&`. 
> 
> Yes, this is technically feasible, but it has the opposite problem from the 
> above: && is very closely associated (in terms of programmer mindspace) with 
> boolean conditionals, and the let/case clauses are *not* boolean conditions.


I initially didn't think && represents a problem, but I realized as I was 
working on this message there definitely is a serious issue: ||. I don’t see 
how you can work around it either and that seems to kill the idea of using && 
no matter how you slice it.

guard
x == 0 &&
let y = optional ||
z == 2 && y == 5 //is y optional or not?!?
else { … }

You can’t have the optional let binding shortcut and use boolean values this 
way. You’d have to figure out if the expression always requires “y = optional” 
to succeed, then y’s type would be non-optional, otherwise y would be optional. 
That seems surprising and confusing.



What I really want is commas to separate different kinds of clauses because 
many cases read cleaner as a single line and C ruined semicolons for me, 
especially their use in for statements.


> 
> The ambiguity is between “case” and “let” conditions, specifically because 
> “case” takes a pattern, and “let” is a valid pattern:
> 
> guard (pattern1) = expr1, let x = expr2 else
> 
> can be:
> 
> guard (pattern1) = expr1, let (x) = expr2 else
> 
> or:
> 
> guard (pattern1) = expr1, (let x) = expr2 else


I am probably missing something but why is this the case? In all of these forms 
the let is unambiguous; it either precedes the enum case or pattern (itself 
enclosed in parens), or the let is contained in the parens.

if case let .Point(x, y) = value, let z = optional { }
if case let (x, y) = value, let z = optional { }
if case .Point(let x, _) = value, let z = optional { }
if case (let x, 1.0) = value where x != 0.0, let z = optional { }



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

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Austin Zheng via swift-evolution]

My original v2 proposal draft suggested making value preserving and human
readable descriptions orthogonal, but Chris and a few other people
suggested they liked the originally suggested design better. I have a link
in the "Alternatives" section to that original draft.

Austin

On Tue, May 31, 2016 at 3:22 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Tue May 31 2016, Thorsten Seitz  wrote:
>
> > I agree with Vladimir. Having a value preserving representation is
> > orthogonal to a human readable representation.
>
> I too think he's making a good point.  I could be missing something, but
> it seems to me we don't fully understand this design yet.
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Ad hoc enums / options

[Hooman Mehr via swift-evolution]

Correction/ Clarification. My assumption. The signature I am assuming is 
actually:


func scaleAndCropImage(
image: UIImage,
toSize size: CGSize,
fitImage: Bool = false
) -> UIImage {

> On May 31, 2016, at 3:27 PM, Hooman Mehr via swift-evolution 
>  wrote:
> 
> If we go back to your original example:
> 
> 
> 
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> fitImage: Bool = true
> ) -> UIImage {
> 
> There is a different type of sugar that I would like to have: Having label 
> stand for `true` when we have a defaulted boolean flag, whose default value 
> is false.
> 
> At call site we either say:
> 
> scaleAndCropImage(image: myImage, toSize: mySize)
> 
> or: 
> 
> scaleAndCropImage(image: myImage, toSize: mySize, fitImage)
> 
> We could still use:
> 
> scaleAndCropImage(image: myImage, toSize: mySize, fitImage: true)
> or
> scaleAndCropImage(image: myImage, toSize: mySize, fitImage: false)
> 
> Note that this is addressing a different situation: When we have multiple 
> boolean flag parameters that can be combined like an OptionSet.
> 
> This is purely sugar: if the identifier matches the label of a defaulted to 
> false boolean flag, it is interpreted as if the flag was passed as true. 
> Other than that there is no effect.
> 
> I also like your idea as long as we put a limitation like what you proposed: 
> Having it strictly be a UInt8 (or whatever) enum. Still the general 
> resilience issues with enums remain and may get more complicated with this 
> addition.
> 
> 
>> On May 31, 2016, at 3:00 PM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> 
>>> On May 31, 2016, at 3:20 PM, Brent Royal-Gordon >> > wrote:
>>> 
 func scaleAndCropImage(
   image: UIImage,
   toSize size: CGSize,
   operation: (.Fit | .Fill) = .Fit
   ) -> UIImage {
>>> 
>>> As I said the last time this proposal came up, I think this is great right 
>>> up until the moment you need `operation` to be computed or kept in a 
>>> variable. Then you need to start copying your anonymous enum type all over 
>>> your source, and there's no central place to make changes. The same thing 
>>> is true of tuples, but tuples are easy to structure and destructure from 
>>> individual values on the spot; anonymous enums aren't really like that.
>> 
>> And the obvious answer is you can have up to 255 of these babies for the 
>> anonymous enum type, and be able to pass numerical equivalents UInt8 with 
>> compile time substitution. That the ad-hoc enumeration is basically a 
>> syntactic shorthand for UInt8, with an enforced upper bound compile time 
>> check simplifies everything including switch statements.
>> 
>> -- 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

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

Re: [swift-evolution] Ad hoc enums / options

[Hooman Mehr via swift-evolution]

If we go back to your original example:



func scaleAndCropImage(
image: UIImage,
toSize size: CGSize,
fitImage: Bool = true
) -> UIImage {

There is a different type of sugar that I would like to have: Having label 
stand for `true` when we have a defaulted boolean flag, whose default value is 
false.

At call site we either say:

scaleAndCropImage(image: myImage, toSize: mySize)

or: 

scaleAndCropImage(image: myImage, toSize: mySize, fitImage)

We could still use:

scaleAndCropImage(image: myImage, toSize: mySize, fitImage: true)
or
scaleAndCropImage(image: myImage, toSize: mySize, fitImage: false)

Note that this is addressing a different situation: When we have multiple 
boolean flag parameters that can be combined like an OptionSet.

This is purely sugar: if the identifier matches the label of a defaulted to 
false boolean flag, it is interpreted as if the flag was passed as true. Other 
than that there is no effect.

I also like your idea as long as we put a limitation like what you proposed: 
Having it strictly be a UInt8 (or whatever) enum. Still the general resilience 
issues with enums remain and may get more complicated with this addition.


> On May 31, 2016, at 3:00 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On May 31, 2016, at 3:20 PM, Brent Royal-Gordon  
>> wrote:
>> 
>>> func scaleAndCropImage(
>>>   image: UIImage,
>>>   toSize size: CGSize,
>>>   operation: (.Fit | .Fill) = .Fit
>>>   ) -> UIImage {
>> 
>> As I said the last time this proposal came up, I think this is great right 
>> up until the moment you need `operation` to be computed or kept in a 
>> variable. Then you need to start copying your anonymous enum type all over 
>> your source, and there's no central place to make changes. The same thing is 
>> true of tuples, but tuples are easy to structure and destructure from 
>> individual values on the spot; anonymous enums aren't really like that.
> 
> And the obvious answer is you can have up to 255 of these babies for the 
> anonymous enum type, and be able to pass numerical equivalents UInt8 with 
> compile time substitution. That the ad-hoc enumeration is basically a 
> syntactic shorthand for UInt8, with an enforced upper bound compile time 
> check simplifies everything including switch statements.
> 
> -- 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] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Paul Cantrell via swift-evolution]

I certainly am warm to that myself, although I’m also sympathetic to what Chris 
wrote about the inconsistency it introduces:

let x = optionalX!, y = optionalY!  // Works!
doStuff(x, y)

if let x = optionalX, y = optionalY {  // Doesn’t work. Confusion!
doStuff(x, y)
}

Also, eliminating the repeated “let” in a big list of conditional bindings is a 
common practice:

if let firstName = json["first_name"],
   lastName = json["last_name"],
   street = json["street"],
   state = json["state"],
   zip = json["zip_code"] {
...   
}

…and some style guides even go out of their way to recommend this over the 
repeated “let.” Popular feature, so I’d be hesitant to nix it.

P

> On May 31, 2016, at 5:04 PM, Hooman Mehr  wrote:
> 
> Exactly what I feel about this. 
> 
> I am prepared to go as far as disallowing:
> 
> let x = optionalX, y = optionalY 
> 
> syntax to free up comma for use instead of semicolon. Then the above becomes:
> 
> let x = optionalX, let y = optionalY
> 
> In this case we will keep the comma at the end of the line as well.
> 
> 
>> On May 31, 2016, at 2:25 PM, Paul Cantrell via swift-evolution 
>> > wrote:
>> 
>> Returning to the list after a brutally busy spring, a demi-review:
>> 
>> I vote…
>> 
>> +1 on addressing this problem,
>> +1 on the proposal’s structural approach (list of items which may be either 
>> boolean tests or bindings, in any order), and
>> +1 on eliminating “where” in the presence of a better approach,
>> 
>> …but am ambivalent about the semicolon. Hereafter follows a slushy 
>> reflection on my deepest inner thoughts and feelings about syntax.
>> 
>> The logic behind the semicolon makes perfect sense, but my initial gut 
>> reaction agrees with others who say it just isn’t pleasant to read. I spent 
>> some time fiddling with places in my code where I’ve used “if … where” and 
>> tried the proposed syntax instead. It feels … off.
>> 
>> Commas in the same spots feel better somehow. I spent some time reflecting 
>> on why this might be, and I think it’s just that my brain is so strongly 
>> trained to parse the semicolon as a statement separator. IOW, my mental 
>> hierarchy is this:
>> 
>>  expression
>>  comma
>>  statement
>>  semicolon ←
>> 
>> …(and this is intuitively true for me despite the C-style for loop), but the 
>> proposal asks us to read this way instead:
>> 
>>  expression
>>  comma
>>  semicolon ←
>>  statement
>> 
>> In particular, my years of C trained me to spot this mistake:
>> 
>>  if(foo < bar);
>>  oopsThisAlwaysExecutes();
>> 
>> …and seeing that semicolon on the same line as the “if” in Swift triggers 
>> that deeply conditioned alarm bell. Then again, “if let” and “if case” have 
>> always felt weirdly wrong to me as well, and I eventually got used to them. 
>> I’d probably get used to this proposed syntax as well.
>> 
>> The line breaks look better than semicolons, but suffer a bit from the same 
>> “statement boundary” brain retraining problem.
>> 
>> Somebody proposed && (Brent maybe?). I tried it out too. It’s surprisingly 
>> pleasant to read, but makes it look like I should be able to arbitrarily 
>> embed bindings deep in expressions in ways that would open hideous cans of 
>> worms:
>> 
>>if let foo = bar && barTest(foo) || let foo = baz && bazTest(foo) {
>>// Is foo defined here? What is its type? Yikes!
>>}
>> 
>> Communicating that the top-level separator in a condition clause is not just 
>> another boolean operator does seem important.
>> 
>> Bottom line: the proposal addresses a real problem, and the proposed 
>> solution is an improvement. If the choice is either current syntax or 
>> SE-0099, I vote for SE-0099. I have a nagging feeling there’s a better third 
>> choice out there somewhere. If there isn’t, then I’ll take SE-0099.
>> 
>> Cheers,
>> 
>> Paul
>> 
>> 
>> ___
>> 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] [Returned for revision] SE-0089: Renaming String.init(_: T)

[Dave Abrahams via swift-evolution]

on Tue May 31 2016, Thorsten Seitz  wrote:

> I agree with Vladimir. Having a value preserving representation is
> orthogonal to a human readable representation.

I too think he's making a good point.  I could be missing something, but
it seems to me we don't fully understand this design yet.

-- 
Dave

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

Re: [swift-evolution] Working with enums by name

[Erica Sadun via swift-evolution]

> On May 31, 2016, at 4:07 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> • also wants OptionSetType-like behavior (and thus an Int raw type).
> 
> Then it's not an `enum`, it's a `struct`.

You can get it for free as an array of enums and test with contains vs member

-- E, who has probably digressed more than she really should
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Working with enums by name

[Brent Royal-Gordon via swift-evolution]

> • also wants OptionSetType-like behavior (and thus an Int raw type).

Then it's not an `enum`, it's a `struct`.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Hooman Mehr via swift-evolution]

Exactly what I feel about this. 

I am prepared to go as far as disallowing:

let x = optionalX, y = optionalY 

syntax to free up comma for use instead of semicolon. Then the above becomes:

let x = optionalX, let y = optionalY

In this case we will keep the comma at the end of the line as well.


> On May 31, 2016, at 2:25 PM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> Returning to the list after a brutally busy spring, a demi-review:
> 
> I vote…
> 
> +1 on addressing this problem,
> +1 on the proposal’s structural approach (list of items which may be either 
> boolean tests or bindings, in any order), and
> +1 on eliminating “where” in the presence of a better approach,
> 
> …but am ambivalent about the semicolon. Hereafter follows a slushy reflection 
> on my deepest inner thoughts and feelings about syntax.
> 
> The logic behind the semicolon makes perfect sense, but my initial gut 
> reaction agrees with others who say it just isn’t pleasant to read. I spent 
> some time fiddling with places in my code where I’ve used “if … where” and 
> tried the proposed syntax instead. It feels … off.
> 
> Commas in the same spots feel better somehow. I spent some time reflecting on 
> why this might be, and I think it’s just that my brain is so strongly trained 
> to parse the semicolon as a statement separator. IOW, my mental hierarchy is 
> this:
> 
>   expression
>   comma
>   statement
>   semicolon ←
> 
> …(and this is intuitively true for me despite the C-style for loop), but the 
> proposal asks us to read this way instead:
> 
>   expression
>   comma
>   semicolon ←
>   statement
> 
> In particular, my years of C trained me to spot this mistake:
> 
>   if(foo < bar);
>   oopsThisAlwaysExecutes();
> 
> …and seeing that semicolon on the same line as the “if” in Swift triggers 
> that deeply conditioned alarm bell. Then again, “if let” and “if case” have 
> always felt weirdly wrong to me as well, and I eventually got used to them. 
> I’d probably get used to this proposed syntax as well.
> 
> The line breaks look better than semicolons, but suffer a bit from the same 
> “statement boundary” brain retraining problem.
> 
> Somebody proposed && (Brent maybe?). I tried it out too. It’s surprisingly 
> pleasant to read, but makes it look like I should be able to arbitrarily 
> embed bindings deep in expressions in ways that would open hideous cans of 
> worms:
> 
>if let foo = bar && barTest(foo) || let foo = baz && bazTest(foo) {
>// Is foo defined here? What is its type? Yikes!
>}
> 
> Communicating that the top-level separator in a condition clause is not just 
> another boolean operator does seem important.
> 
> Bottom line: the proposal addresses a real problem, and the proposed solution 
> is an improvement. If the choice is either current syntax or SE-0099, I vote 
> for SE-0099. I have a nagging feeling there’s a better third choice out there 
> somewhere. If there isn’t, then I’ll take SE-0099.
> 
> Cheers,
> 
> Paul
> 
> 
> ___
> 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] Working with enums by name

[Paul Cantrell via swift-evolution]

> On May 31, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> |   enum Planet : Int {
>> |  case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
>> |
>> |  init?(caseName name : String) {
> 
> The compiler actually does this already through RawRepresentable if you put 
> `String` as your raw type. So what's the use case for this? Code which needs 
> both a non-String rawValue *and* needs to look up cases by name? How common 
> do you think that is?

How about a LogCategory enum:

• whose name is printed with each log entry (and thus wants a String raw type),
• which can be configured from command line or config file (and thus wants 
string-based lookup), but
• also wants OptionSetType-like behavior (and thus an Int raw type).

P

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

Re: [swift-evolution] Ad hoc enums / options

[Erica Sadun via swift-evolution]

> On May 31, 2016, at 3:20 PM, Brent Royal-Gordon  
> wrote:
> 
>> func scaleAndCropImage(
>>image: UIImage,
>>toSize size: CGSize,
>>operation: (.Fit | .Fill) = .Fit
>>) -> UIImage {
> 
> As I said the last time this proposal came up, I think this is great right up 
> until the moment you need `operation` to be computed or kept in a variable. 
> Then you need to start copying your anonymous enum type all over your source, 
> and there's no central place to make changes. The same thing is true of 
> tuples, but tuples are easy to structure and destructure from individual 
> values on the spot; anonymous enums aren't really like that.

And the obvious answer is you can have up to 255 of these babies for the 
anonymous enum type, and be able to pass numerical equivalents UInt8 with 
compile time substitution. That the ad-hoc enumeration is basically a syntactic 
shorthand for UInt8, with an enforced upper bound compile time check simplifies 
everything including switch statements.

-- E

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

Re: [swift-evolution] Variadic generics discussion

[L Mihalkovic via swift-evolution]

> On May 31, 2016, at 9:49 PM, Chris Lattner  wrote:
> 
> 
>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution 
>> > wrote:
>> 
>> well there is no macro system, and for the moment a clear statement from 
>> chris that this is not on the table in the short term. the code in the 
>> example looked like run-of-the-mill swift, except for the “…". so that 
>> leaves us with swift looking code that would be executed by the compiler, 
>> but with nothing particular to tell which parts to and which not. just a 
>> thought.
> 
> Lets be clear though: variadic generics are not in scope for Swift 3 either.  

+1

> 
> I definitely don’t speak for the rest of the core team, nor have I discussed 
> it with them…  but IMO, this whole feature seems like a better fit for a

> macro system

+++1

> than it does to complicate the generics system.  Unlike C++’s template 
> system, our generics system inherently has runtime / dynamic dispatch 
> properties, and I don’t think that shoehorning variadics into it is going to 
> work out well.

just for my education and purely as a thought experiment: couldn’t a purely 
runtime system based on some assistance from the compiler via a couple of 
synthesized ‘magic’ variables inside the scope of a function provide access to 
the types and the values as tuples?  that would only give variadic generic 
functions, but that is something in itself.  I would never claim the idea, but 
it looks close enough to what D is doing. 

> 
> -Chris
> 
>> 
>> 
>>> On May 31, 2016, at 7:59 PM, Austin Zheng >> > wrote:
>>> 
>>> How so? I'm interested in anything that can get us away from having to 
>>> generating code at compile-time.
>>> 
>>> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic 
>>> > wrote:
>>> 
>>> What's interesting about the code in the manifesto is that it looks very 
>>> much like "..." is a runtime construct, as opposed to trying the get the 
>>> compiler to do the heavy lifting.
>>> 
>> 
>> ___
>> 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] Ad hoc enums / options

[Brent Royal-Gordon via swift-evolution]

> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> operation: (.Fit | .Fill) = .Fit
> ) -> UIImage {

As I said the last time this proposal came up, I think this is great right up 
until the moment you need `operation` to be computed or kept in a variable. 
Then you need to start copying your anonymous enum type all over your source, 
and there's no central place to make changes. The same thing is true of tuples, 
but tuples are easy to structure and destructure from individual values on the 
spot; anonymous enums aren't really like that.

And this problem starts occurring *very* quickly. I mean, you've left 
`scaleAndCropImage`'s implementation out. Imagine implementing it with a couple 
helper functions, and you start to see this problem occurring:

func scaleAndCrop(image: UIImage, to size: CGSize, operation: (.fit | 
.fill) = .fit) -> UIImage {
let drawingRect = rect(of: size, for: operation)
return drawnImage(image, in: drawingRect)
}

private func rect(of size: CGSize, for operation: (.fit | .fill)) -> 
CGRect {

Already we have one duplication; if we add .fillWidth and .fillHeight modes, 
we'll need to change signatures in two places.

In short, when you dig into this proposal and start thinking of use cases that 
are even slightly less than completely trivial, I think the case for it falls 
apart.

(It's also worth noting that this isn't suitable for options, because it 
creates an anonymous enum, not an anonymous option set.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Ad hoc enums / options

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 3:46 PM, Vladimir.S  wrote:
> 
> > If you are not allowing callers to store their argument in a variable then
> > I am 100% opposed to this.  That would the first case in Swift where you
> > *MUST* provide a literal argument when calling a function, and *CANNOT*
> > provide a value you store in a variable (possibly something you receive as
> > an argument from somewhere else).  Why would we want to restrict the
> > flexibility of callers in that way?
> 
> Definitely we *must* be able to use a variable in call to function. The 
> problem is how (in case we agreee that the proposed feature could be useful).
> 
> I'm thinking about similarity of tuples and this anonymous enums.. If you 
> have tuple in function parameter - how would you use variable to pass it to 
> function? You'll define a variable of the exact same tuple as required, 
> manually, no some separate type provided for this. Yes, if tuple in function 
> definition changed - you'll need to change tuple on caller side:
> 
> func foo(int: Int, tuple: (Int, String)) {}
> 
> foo(1, tuple: (1, "string"))
> 
> var tupleVar : (Int, String) = (1, "string")
> 
> foo(1, tuple: tupleVar)
> 
> So, why not have the same for such anonymous enums?
> 
> func foo(int: Int, variant: (.one | .two)) {}
> 
> foo(1, variant: .one)
> 
> var enumVar : (.one | .two) = .one
> 
> foo(1, variant: enumVar)
> 
> 
> Seems like consistent solution.

It is consistent with tuples, but using a tuple instead of distinct parameters 
is usually going to be a bad idea.  If we introduce ad-hoc enums people are 
going to use it frequently.  And options like this are the kind of thing that 
*does* change periodically.  

Because those changes are usually additive I’m not too concerned about removing 
options.  But I *am* concerned about re-ordering existing options or adding new 
options impacting existing variable declarations.  For this reason, these would 
need to be order-independent and support structural subtyping.  That way my 
`(.foo | .bar)` variable is still a valid argument when you change the option 
list to `(.baz | .bar | .foo)`.

The existing approach of just defining an enum is really not so bad and removes 
this issue altogether.  IMO it is a reasonable “workaround” for now.

I believe there is a lot of overlap between doing this the right way and 
introducing structural unions like those in Ceylon (fortunately there seems to 
be growing support for this).  For that reason I think it makes sense to wait 
until we have that feature to look at ad-hoc types with enumerated values like 
this.

> 
> 
> On 31.05.2016 22:07, Matthew Johnson via swift-evolution wrote:
>> 
>>> On May 31, 2016, at 2:04 PM, Erica Sadun >> 
>>> >> wrote:
>>> 
 
 On May 31, 2016, at 12:35 PM, Matthew Johnson 
 >> wrote:
 
 I think I'm -1 on this.  It makes things easier for the implementer of
 the function and harder for the caller.
 
 It's not clear whether the caller could store an argument to pass in a
 variable, but if they could they would need to list out all cases in the
 type of the variable (unless these anonymous enums have structural
 subtyping).  This is fragile.  Any time that list changes all variable
 declarations will have to be updated.
 
 Functions are implemented once and usually called more many times.  It's
 better for callers if you just write it like this:
 
 enum FitOrFill { case fit, fill }
 func scaleAndCropImage(
image: UIImage,
toSize size: CGSize,
*operation: FitOrFill = .fit*
) -> UIImage {
 
 
 So unless these anonymous enums are structurally subtyped I think it's a
 bad idea.  And introducing structural subtyping here seems like a pretty
 large hammer for this use case.
>>> 
>>> 
>>> From the caller's point of view, the type must be inferable and exactly
>>> match a token listed in the declaration (which would also appear in Quick
>>> Help):
>>> 
>>> let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill)
>>> 
>>> You would not be able to assign `.fill` to a variable and use that for
>>> the operation value.
>> 
>> If you are not allowing callers to store their argument in a variable then
>> I am 100% opposed to this.  That would the first case in Swift where you
>> *MUST* provide a literal argument when calling a function, and *CANNOT*
>> provide a value you store in a variable (possibly something you receive as
>> an argument from somewhere else).  Why would we want to restrict the
>> flexibility of callers in that way?
>> 
>>> 
>>> -- E
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> 

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[Brent Royal-Gordon via swift-evolution]

>case spades {

>let bezierPath = UIBezierPath()

Does each instance of `.spades` have a *separate* UIBezierPath, or do all 
instances of `.spades` share one? If it's the former, I have strong doubts 
you'll actually get this through. If it's the latter, that isn't really what 
this syntax suggests is happening.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Xiaodi Wu via swift-evolution]

On Tue, May 31, 2016 at 3:43 PM, Brandon Knope  wrote:

> Why would that argue for the removal of where
>
> if let y = y where y != 5 && x < z
>
> I would still prefer:
> if let y = y where y != 5, x < z, let z = someOptional where z == 10
>
> To me, where still has a place. And that place is saying "hey this is a
> recently introduced or shadowed variable, so don't go looking very far for
> what is referring to".
>
> If I understand correctly, this would be rewritten in the proposed syntax
> as:
>
> if let y = y; y != 5; x < z; let z = someOptional; z == 10 { }
>
> Which technically could be written as:
>
> if let y = y; x < z; let z = someOptional; z == 10; y != 5 { } // y != 5
> arbitrarily moved to the end
>
> Now y != 5 is at the end and a quick glimpse of this line could be
> confusing:
> 1. Is this y a previous variable like x is?
> 2. Is it a shadowed variable?
>


Sure; but as has been mentioned on this list before, these concerns about
style are what linters are for, not the compiler.


>
> This kind of information is lost while glancing the line (and people do
> glance especially with long conditional clauses). This makes having where
> relevant in my opinion. It aids in readability and expressiveness.
>
> Brandon
>
>
> On May 31, 2016, at 4:25 PM, Xiaodi Wu  wrote:
>
> On Tue, May 31, 2016 at 3:16 PM, Brandon Knope  wrote:
>
>> And why couldn't we propose that it should?
>>
>
> And that is this proposal; the options considered for the spelling are
> comma, semicolon, and `&&`.
>
> Now we circle back to my earlier point. The introduction of any of these
> would argue for the elimination of `where`, for the reasons I've stated
> above. Briefly, everything that can be expressed using `where` could be
> expressed using the comma, semicolon, or `&&`. Since there is no good way
> to enforce the semantic relationship requirement for `where`, only a proxy
> rule about variable names can be contemplated, which as I've demonstrated
> is ineffective.
>
> If you're asking why commas or semicolons have been proposed instead of
> `&&`, that argument has been made above by others.
>
>
> Brandon
>>
>> On May 31, 2016, at 4:14 PM, Xiaodi Wu  wrote:
>>
>> On Tue, May 31, 2016 at 3:08 PM, Brandon Knope  wrote:
>>
>>> What is wrong with:
>>>
>>> if let y = y && x < z
>>>
>>> They are, after all, independent from each other.
>>>
>>
>> That won't compile.
>>
>>
>> Brandon
>>>
>>> On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution
>>>  wrote:
>>>

 On May 31, 2016, at 1:47 PM, Xiaodi Wu  wrote:



 On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via
 swift-evolution  wrote:

>
>> Not allowed:
>> …
>> let a = a
>> let b = b where b > 10 && a > 5
>>
>
> Why would this not be allowed by your rule? You're making use of `b`
> in your where clause. As I demonstrated above, essentially any assertion
> can be rewritten to work around your rule. In general:
>
>
> It is not allowed because  ‘a’ is defined in the line above. It must
> be defined in the ‘if let’ associated with the where in which it is
> mentioned.
>

 That's a much more restrictive where clause than you proposed earlier.
 You'd not be able to write:

 ```
 let b = b where b > anyOtherVariable
 ```


 The definition is not a formal one, but that was the intent.

 ```
 let b = b where b > anyOtherVariable
 ```

 is legal as long as `anyOtherVariable` is not defined within the entire
 condition clause

>>>
>>>
>>> You can propose that rule, but it doesn't solve the issue. If, today,
>>> I've got
>>>
>>> ```
>>> let x = 1
>>> let y: Int? = 2
>>> let z = 3
>>>
>>> if let y = y where x < z {
>>>   // do stuff
>>> }
>>> ```
>>>
>>> your rule simply forces
>>>
>>> ```
>>> if let y = y where y == y && x < z {
>>>   // do stuff
>>> }
>>> ```
>>>
>>> The point is, the semantic relationship between what comes before and
>>> after `where` exists in the mind of the human reader only.
>>>
>>> ___
>>> 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-0099: Restructuring Condition Clauses

[Brandon Knope via swift-evolution]

Except I disagree. 

It might seem like a stylistic flourish, but it can be more expressive in 
informing the reader that the variable after the where clause was recently 
introduced somewhere in the preceding clause. 

Without it, you'd have to scan the entire conditional clause and around the 
conditional statement to find a variable. 

let x = 5

 6 lines later 

let y = y where y == 10, x == 5

having the where here makes it clear that x was introduced elsewhere. You might 
not have known that because x was introduced several lines up. 

It's contrived, but imagine a very long conditional or guard statement and I 
think where still has a place especially in aiding readability. 

B

> On May 31, 2016, at 4:31 PM, Xiaodi Wu  wrote:
> 
>> On Tue, May 31, 2016 at 3:16 PM, Brandon Knope  wrote:
>> What is wrong with:
>> 
>> if let x = x where x > 10, y != 5, let z = z where z != x
>> 
>> Just as a contrived example?
> 
> Because any grammar that permits what you propose would necessarily permit:
> 
> ```
> if let x = x, x > 10, y != 5, let z = z, z != x
> ```
> 
> Thus, `where` becomes redundant, a vestigial stylistic flourish.
> 
>> 
>> Brandon 
>> 
>>> On May 31, 2016, at 4:03 PM, Xiaodi Wu  wrote:
>>> 
 On Tue, May 31, 2016 at 2:59 PM, Brandon Knope  wrote:
 Except "b" is the main focus of the where clause and b was just in the 
 preceding if condition. 
 
 I feel like we are trying to find ways to break the current where clause 
 even though we've enjoyed it for almost a year now. I had no idea it was 
 problematic and restrictive. I thought it made its intent very 
 clear...leading to very readable code. 
 
 Pretty soon almost every construct but conditionals will be allowed to 
 have where clauses, and THAT seems inconsistent to me. 
 
 ...what exactly is the current problem? Can someone show me a real world 
 example?? I've already forgotten it in all of this discussion -_-
>>> 
>>> The origin of the problem is a simple question: how does one test for 
>>> something unrelated to the variable that's bound in an `if let` statement? 
>>> The answer is: in today's Swift, any such test after the first `let` must 
>>> come after `where`. This is problematic and restrictive because one is 
>>> forced to imply a semantic relationship that doesn't exist.
>>>  
 Brandon 
 
> On May 31, 2016, at 3:47 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> 
> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution 
>  wrote:
 
 Not allowed:
 …
 let a = a
 let b = b where b > 10 && a > 5
>>> 
>>> Why would this not be allowed by your rule? You're making use of `b` in 
>>> your where clause. As I demonstrated above, essentially any assertion 
>>> can be rewritten to work around your rule. In general:
>> 
>> It is not allowed because  ‘a’ is defined in the line above. It must be 
>> defined in the ‘if let’ associated with the where in which it is 
>> mentioned.
> 
> That's a much more restrictive where clause than you proposed earlier. 
> You'd not be able to write:
> 
> ```
> let b = b where b > anyOtherVariable
> ``` 
> 
> ___
> 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] Variadic generics discussion

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 3:39 PM, Austin Zheng  wrote:
> 
> (inline)
> 
> On Tue, May 31, 2016 at 1:34 PM, Matthew Johnson  > wrote:
> 
>> On May 31, 2016, at 3:25 PM, Austin Zheng > > wrote:
>> 
>> I have a proposal for #6 in the pipe, but there are actually some subtleties 
>> I have to work out (it's not as simple as just slapping a generic type 
>> signature on a let constant).
> 
> Cool.  Looking forward to reviewing a draft when it’s ready.
> 
>> 
>> I think #5 is just considered a 'bug' and doesn't need a proposal (it might 
>> actually be finished already; I saw some commits recently); same with #4. #7 
>> is not very useful without variadic generics (it pretty much exists to allow 
>> tuples to conform to protocols, and tuples are inherently variadic).
>> 
> 
> Good to know 4 and 5 are considered bugs.  I know #4 is important for the 
> standard library so I suppose that will ensure it is a priority soon enough.
> 
> I included #7 because it would still be nice to have for a number of reasons. 
>  Maybe there is a way to pull it off for a handful of types that are known to 
> the compiler.
> 
>> I wanted to take a stab at #2. 
> 
> Are you still thinking about this one or did you decide not to pursue it?
> 
> I think I'd like to try writing something up.
>  
> 
>> The core team has talked so much about #1 that I'd be surprised if they 
>> don't already have an idea as to how they want to do it, plus it's 
>> complicated for a number of reasons to get right. In such a case having the 
>> community push forward an alternate proposal would just be giving everyone 
>> more unneeded work.
> 
> Agree here as well.  I’ve avoided generics proposals mostly because I thought 
> the core team was leading the charge on all them.  It now appears like that 
> may not have been the right assumption across the board.  I wish we had a bit 
> more visibility on this...
> 
> Yes, same. I'm going off this bullet point at the beginning of the generics 
> manifesto:
> 
> "I hope to achieve several things: ... Engage more of the community in 
> discussions of specific generics features, so we can coalesce around designs 
> for public review. And maybe even get some of them implemented."
>  
> 
>> 
>> #3 seems semantically straightforward. AFAIK there's nothing a subscript can 
>> do that a getter and setter method can't do together, and methods can 
>> already be generic. A proposal shouldn't be hard to put together.
> 
> Agree.  Someone just needs to jump in and write it up.  :-)  If it had a 
> chance of making it into Swift 3 I would do it right away, but it’s hard to 
> tell...
> 
> I'd be happy to write up a proposal, especially if it's as straightforward as 
> it seems.

Cool!  I’ll continue to play the role of providing as much feedback as I can…  
:-)


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

Re: [swift-evolution] Ad hoc enums / options

[Vladimir.S via swift-evolution]

> If you are not allowing callers to store their argument in a variable then
> I am 100% opposed to this.  That would the first case in Swift where you
> *MUST* provide a literal argument when calling a function, and *CANNOT*
> provide a value you store in a variable (possibly something you receive as
> an argument from somewhere else).  Why would we want to restrict the
> flexibility of callers in that way?

Definitely we *must* be able to use a variable in call to function. The 
problem is how (in case we agreee that the proposed feature could be useful).


I'm thinking about similarity of tuples and this anonymous enums.. If you 
have tuple in function parameter - how would you use variable to pass it to 
function? You'll define a variable of the exact same tuple as required, 
manually, no some separate type provided for this. Yes, if tuple in 
function definition changed - you'll need to change tuple on caller side:


func foo(int: Int, tuple: (Int, String)) {}

foo(1, tuple: (1, "string"))

var tupleVar : (Int, String) = (1, "string")

foo(1, tuple: tupleVar)

So, why not have the same for such anonymous enums?

func foo(int: Int, variant: (.one | .two)) {}

foo(1, variant: .one)

var enumVar : (.one | .two) = .one

foo(1, variant: enumVar)


Seems like consistent solution.


On 31.05.2016 22:07, Matthew Johnson via swift-evolution wrote:



On May 31, 2016, at 2:04 PM, Erica Sadun > wrote:



On May 31, 2016, at 12:35 PM, Matthew Johnson > wrote:

I think I'm -1 on this.  It makes things easier for the implementer of
the function and harder for the caller.

It's not clear whether the caller could store an argument to pass in a
variable, but if they could they would need to list out all cases in the
type of the variable (unless these anonymous enums have structural
subtyping).  This is fragile.  Any time that list changes all variable
declarations will have to be updated.

Functions are implemented once and usually called more many times.  It's
better for callers if you just write it like this:

enum FitOrFill { case fit, fill }
func scaleAndCropImage(
image: UIImage,
toSize size: CGSize,
*operation: FitOrFill = .fit*
) -> UIImage {


So unless these anonymous enums are structurally subtyped I think it's a
bad idea.  And introducing structural subtyping here seems like a pretty
large hammer for this use case.



From the caller's point of view, the type must be inferable and exactly
match a token listed in the declaration (which would also appear in Quick
Help):

let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill)

You would not be able to assign `.fill` to a variable and use that for
the operation value.


If you are not allowing callers to store their argument in a variable then
I am 100% opposed to this.  That would the first case in Swift where you
*MUST* provide a literal argument when calling a function, and *CANNOT*
provide a value you store in a variable (possibly something you receive as
an argument from somewhere else).  Why would we want to restrict the
flexibility of callers in that way?



-- 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] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Brandon Knope via swift-evolution]

Why would that argue for the removal of where

if let y = y where y != 5 && x < z

I would still prefer:
if let y = y where y != 5, x < z, let z = someOptional where z == 10

To me, where still has a place. And that place is saying "hey this is a 
recently introduced or shadowed variable, so don't go looking very far for what 
is referring to". 

If I understand correctly, this would be rewritten in the proposed syntax as:

if let y = y; y != 5; x < z; let z = someOptional; z == 10 { }

Which technically could be written as:

if let y = y; x < z; let z = someOptional; z == 10; y != 5 { } // y != 5 
arbitrarily moved to the end 

Now y != 5 is at the end and a quick glimpse of this line could be confusing:
1. Is this y a previous variable like x is?
2. Is it a shadowed variable?

This kind of information is lost while glancing the line (and people do glance 
especially with long conditional clauses). This makes having where relevant in 
my opinion. It aids in readability and expressiveness. 

Brandon 




> On May 31, 2016, at 4:25 PM, Xiaodi Wu  wrote:
> 
>> On Tue, May 31, 2016 at 3:16 PM, Brandon Knope  wrote:
>> And why couldn't we propose that it should?
> 
> And that is this proposal; the options considered for the spelling are comma, 
> semicolon, and `&&`.
> 
> Now we circle back to my earlier point. The introduction of any of these 
> would argue for the elimination of `where`, for the reasons I've stated 
> above. Briefly, everything that can be expressed using `where` could be 
> expressed using the comma, semicolon, or `&&`. Since there is no good way to 
> enforce the semantic relationship requirement for `where`, only a proxy rule 
> about variable names can be contemplated, which as I've demonstrated is 
> ineffective.
> 
> If you're asking why commas or semicolons have been proposed instead of `&&`, 
> that argument has been made above by others.
> 
> 
>> Brandon 
>> 
>>> On May 31, 2016, at 4:14 PM, Xiaodi Wu  wrote:
>>> 
 On Tue, May 31, 2016 at 3:08 PM, Brandon Knope  wrote:
 What is wrong with:
 
 if let y = y && x < z
 
 They are, after all, independent from each other.
>>> 
>>> That won't compile.
>>>  
>>> 
 Brandon 
 
> On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution 
>>  wrote:
> 
>> 
>>> On May 31, 2016, at 1:47 PM, Xiaodi Wu  wrote:
>>> 
>>> 
>>> 
>>> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via 
>>> swift-evolution  wrote:
>> 
>> Not allowed:
>> …
>> let a = a
>> let b = b where b > 10 && a > 5
> 
> Why would this not be allowed by your rule? You're making use of `b` 
> in your where clause. As I demonstrated above, essentially any 
> assertion can be rewritten to work around your rule. In general:
 
 It is not allowed because  ‘a’ is defined in the line above. It must 
 be defined in the ‘if let’ associated with the where in which it is 
 mentioned.
>>> 
>>> That's a much more restrictive where clause than you proposed earlier. 
>>> You'd not be able to write:
>>> 
>>> ```
>>> let b = b where b > anyOtherVariable
>>> ```
>> 
>> 
>> The definition is not a formal one, but that was the intent.
>> 
>> ```
>> let b = b where b > anyOtherVariable
>> ```
>> is legal as long as `anyOtherVariable` is not defined within the entire 
>> condition clause
> 
> 
> You can propose that rule, but it doesn't solve the issue. If, today, 
> I've got
> 
> ```
> let x = 1
> let y: Int? = 2
> let z = 3
> 
> if let y = y where x < z {
>   // do stuff
> }
> ```
> 
> your rule simply forces
> 
> ```
> if let y = y where y == y && x < z {
>   // do stuff
> }
> ```
> 
> The point is, the semantic relationship between what comes before and 
> after `where` exists in the mind of the human reader only.
> 
> ___
> 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] Variadic generics discussion

[Austin Zheng via swift-evolution]

(inline)

On Tue, May 31, 2016 at 1:34 PM, Matthew Johnson 
wrote:

>
> On May 31, 2016, at 3:25 PM, Austin Zheng  wrote:
>
> I have a proposal for #6 in the pipe, but there are actually some
> subtleties I have to work out (it's not as simple as just slapping a
> generic type signature on a let constant).
>
>
> Cool.  Looking forward to reviewing a draft when it’s ready.
>
>
> I think #5 is just considered a 'bug' and doesn't need a proposal (it
> might actually be finished already; I saw some commits recently); same with
> #4. #7 is not very useful without variadic generics (it pretty much exists
> to allow tuples to conform to protocols, and tuples are inherently
> variadic).
>
>
> Good to know 4 and 5 are considered bugs.  I know #4 is important for the
> standard library so I suppose that will ensure it is a priority soon enough.
>
> I included #7 because it would still be nice to have for a number of
> reasons.  Maybe there is a way to pull it off for a handful of types that
> are known to the compiler.
>
> I wanted to take a stab at #2.
>
>
> Are you still thinking about this one or did you decide not to pursue it?
>

I think I'd like to try writing something up.


>
> The core team has talked so much about #1 that I'd be surprised if they
> don't already have an idea as to how they want to do it, plus it's
> complicated for a number of reasons to get right. In such a case having the
> community push forward an alternate proposal would just be giving everyone
> more unneeded work.
>
>
> Agree here as well.  I’ve avoided generics proposals mostly because I
> thought the core team was leading the charge on all them.  It now appears
> like that may not have been the right assumption across the board.  I wish
> we had a bit more visibility on this...
>

Yes, same. I'm going off this bullet point at the beginning of the generics
manifesto:

"I hope to achieve several things: ... Engage more of the community in
discussions of specific generics features, so we can coalesce around
designs for public review. And maybe even get some of them implemented."


>
>
> #3 seems semantically straightforward. AFAIK there's nothing a subscript
> can do that a getter and setter method can't do together, and methods can
> already be generic. A proposal shouldn't be hard to put together.
>
>
> Agree.  Someone just needs to jump in and write it up.  :-)  If it had a
> chance of making it into Swift 3 I would do it right away, but it’s hard to
> tell...
>

I'd be happy to write up a proposal, especially if it's as straightforward
as it seems.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Variadic generics discussion

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 3:25 PM, Austin Zheng  wrote:
> 
> I have a proposal for #6 in the pipe, but there are actually some subtleties 
> I have to work out (it's not as simple as just slapping a generic type 
> signature on a let constant).

Cool.  Looking forward to reviewing a draft when it’s ready.

> 
> I think #5 is just considered a 'bug' and doesn't need a proposal (it might 
> actually be finished already; I saw some commits recently); same with #4. #7 
> is not very useful without variadic generics (it pretty much exists to allow 
> tuples to conform to protocols, and tuples are inherently variadic).
> 

Good to know 4 and 5 are considered bugs.  I know #4 is important for the 
standard library so I suppose that will ensure it is a priority soon enough.

I included #7 because it would still be nice to have for a number of reasons.  
Maybe there is a way to pull it off for a handful of types that are known to 
the compiler.

> I wanted to take a stab at #2.

Are you still thinking about this one or did you decide not to pursue it?

> The core team has talked so much about #1 that I'd be surprised if they don't 
> already have an idea as to how they want to do it, plus it's complicated for 
> a number of reasons to get right. In such a case having the community push 
> forward an alternate proposal would just be giving everyone more unneeded 
> work.

Agree here as well.  I’ve avoided generics proposals mostly because I thought 
the core team was leading the charge on all them.  It now appears like that may 
not have been the right assumption across the board.  I wish we had a bit more 
visibility on this...

> 
> #3 seems semantically straightforward. AFAIK there's nothing a subscript can 
> do that a getter and setter method can't do together, and methods can already 
> be generic. A proposal shouldn't be hard to put together.

Agree.  Someone just needs to jump in and write it up.  :-)  If it had a chance 
of making it into Swift 3 I would do it right away, but it’s hard to tell...

> 
> Let me know your thoughts.
> 
> Best,
> Austin
> 
> 
> 
> 
> On Tue, May 31, 2016 at 1:16 PM, Matthew Johnson  > wrote:
> 
>> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution 
>> > wrote:
>> 
>> This is pretty much where my thinking about the topic has led me as well. 
>> I'll resign this topic to pursue some other, hopefully more relevant work, 
>> although anyone who wants to continue the discussion is welcome to.
> 
> Seems reasonable to wait until we can at least evaluate the macro approach 
> properly.
> 
> Are you planning to continue work on generics?  FWIW, my top priority list 
> for items without proposals is roughly:
> 
> 1. Conditional conformance 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-
>  
> )
> 2. Parameterized extensions 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions
>  
> )
> 3. Generic subscripts 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts
>  
> )
> 4. Recursive protocol constraints 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics
>  
> )
> 5. Nested generics 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics
>  
> )
> 6. Default generic arguments 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-generic-arguments
>  
> )
> 7. Extensions of structural types 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
>  
> )
> 
> And this one seems like low hanging fruit:
> 
> Default implementations in protocols 
> (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols-
>  
> )
> 
> How does this compare to your priorities for generics?
> 
>> 
>> On Tue, May 31, 2016 at 12:49 PM, Chris Lattner > > wrote:
>> 
>>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution 
>>> 

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

[Vladimir.S via swift-evolution]

On 31.05.2016 22:37, Chris Lattner wrote:

1) Introduce a new declmodifier named something like “atomiclazy”.
2) Disallow global and static variables, unless they are explicitly marked
atomiclazy (compiler would provide a fixit hint to suggest this).
3) Replace the atomiclazy magic with a property behavior when they exist.

In this model, you’d presumably have the choice about atomiclazy or lazy
when setting up either a static or a local property.


OK, I like this direction. I.e. instead of changing current behavior of 
static/global variables, we require explicit decoration for them with 
`atomiclazy` and so their behavior becomes self-documented and it is clear 
from definition that this behavior is different than just `lazy`. One can't 
expect that `atomiclazy` is the same as `lazy`.


This appends some complexity to the language to syntax but also add clarity 
and self-documentation to behavior of defined static/global variables.


As I understand, we need this `atomiclazy` only if static variable has 
initialization block like here:


class A {
static atomiclazy var p : Int = {10}()
}

but this will not require atomiclazy :

class A {
static var p = 10
}

Opinions on this?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Xiaodi Wu via swift-evolution]

On Tue, May 31, 2016 at 3:16 PM, Brandon Knope  wrote:

> What is wrong with:
>
> if let x = x where x > 10, y != 5, let z = z where z != x
>
> Just as a contrived example?
>

Because any grammar that permits what you propose would necessarily permit:

```
if let x = x, x > 10, y != 5, let z = z, z != x
```

Thus, `where` becomes redundant, a vestigial stylistic flourish.


> Brandon
>
> On May 31, 2016, at 4:03 PM, Xiaodi Wu  wrote:
>
> On Tue, May 31, 2016 at 2:59 PM, Brandon Knope  wrote:
>
>> Except "b" is the main focus of the where clause and b was just in the
>> preceding if condition.
>>
>> I feel like we are trying to find ways to break the current where clause
>> even though we've enjoyed it for almost a year now. I had no idea it was
>> problematic and restrictive. I thought it made its intent very
>> clear...leading to very readable code.
>>
>> Pretty soon almost every construct but conditionals will be allowed to
>> have where clauses, and THAT seems inconsistent to me.
>>
>> ...what exactly is the current problem? Can someone show me a real world
>> example?? I've already forgotten it in all of this discussion -_-
>>
>>
> The origin of the problem is a simple question: how does one test for
> something unrelated to the variable that's bound in an `if let` statement?
> The answer is: in today's Swift, any such test after the first `let` must
> come after `where`. This is problematic and restrictive because one is
> forced to imply a semantic relationship that doesn't exist.
>
>
>> Brandon
>>
>> On May 31, 2016, at 3:47 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution
>>  wrote:
>>
>>>
 Not allowed:
 …
 let a = a
 let b = b where b > 10 && a > 5

>>>
>>> Why would this not be allowed by your rule? You're making use of `b` in
>>> your where clause. As I demonstrated above, essentially any assertion can
>>> be rewritten to work around your rule. In general:
>>>
>>>
>>> It is not allowed because  ‘a’ is defined in the line above. It must be
>>> defined in the ‘if let’ associated with the where in which it is mentioned.
>>>
>>
>> That's a much more restrictive where clause than you proposed earlier.
>> You'd not be able to write:
>>
>> ```
>> let b = b where b > anyOtherVariable
>> ```
>>
>> ___
>> 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] Variadic generics discussion

[Austin Zheng via swift-evolution]

(I should mention that this is all just my personal read on the situation,
and shouldn't be construed as trying to stop or induce anyone else from
doing anything. Would love to see other proposals on generics, if people
want to work on them.)

On Tue, May 31, 2016 at 1:25 PM, Austin Zheng  wrote:

> I have a proposal for #6 in the pipe, but there are actually some
> subtleties I have to work out (it's not as simple as just slapping a
> generic type signature on a let constant).
>
> I think #5 is just considered a 'bug' and doesn't need a proposal (it
> might actually be finished already; I saw some commits recently); same with
> #4. #7 is not very useful without variadic generics (it pretty much exists
> to allow tuples to conform to protocols, and tuples are inherently
> variadic).
>
> I wanted to take a stab at #2. The core team has talked so much about #1
> that I'd be surprised if they don't already have an idea as to how they
> want to do it, plus it's complicated for a number of reasons to get right.
> In such a case having the community push forward an alternate proposal
> would just be giving everyone more unneeded work.
>
> #3 seems semantically straightforward. AFAIK there's nothing a subscript
> can do that a getter and setter method can't do together, and methods can
> already be generic. A proposal shouldn't be hard to put together.
>
> Let me know your thoughts.
>
> Best,
> Austin
>
>
>
>
> On Tue, May 31, 2016 at 1:16 PM, Matthew Johnson 
> wrote:
>
>>
>> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> This is pretty much where my thinking about the topic has led me as well.
>> I'll resign this topic to pursue some other, hopefully more relevant work,
>> although anyone who wants to continue the discussion is welcome to.
>>
>>
>> Seems reasonable to wait until we can at least evaluate the macro
>> approach properly.
>>
>> Are you planning to continue work on generics?  FWIW, my top priority
>> list for items without proposals is roughly:
>>
>> 1. Conditional conformance (
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-
>> )
>> 2. Parameterized extensions (
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions
>> )
>> 3. Generic subscripts (
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts
>> )
>> 4. Recursive protocol constraints (
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics
>> )
>> 5. Nested generics (
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics
>> )
>> 6. Default generic arguments (
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-generic-arguments
>> )
>> 7. Extensions of structural types (
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
>> )
>>
>> And this one seems like low hanging fruit:
>>
>> Default implementations in protocols (
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols-
>> )
>>
>> How does this compare to your priorities for generics?
>>
>>
>> On Tue, May 31, 2016 at 12:49 PM, Chris Lattner 
>> wrote:
>>
>>>
>>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> well there is no macro system, and for the moment a clear statement from
>>> chris that this is not on the table in the short term. the code in the
>>> example looked like run-of-the-mill swift, except for the “…". so that
>>> leaves us with swift looking code that would be executed by the compiler,
>>> but with nothing particular to tell which parts to and which not. just a
>>> thought.
>>>
>>>
>>> Lets be clear though: variadic generics are not in scope for Swift 3
>>> either.
>>>
>>> I definitely don’t speak for the rest of the core team, nor have I
>>> discussed it with them…  but IMO, this whole feature seems like a better
>>> fit for a macro system than it does to complicate the generics system.
>>> Unlike C++’s template system, our generics system inherently has runtime /
>>> dynamic dispatch properties, and I don’t think that shoehorning variadics
>>> into it is going to work out well.
>>>
>>> -Chris
>>>
>>>
>>>
>>> On May 31, 2016, at 7:59 PM, Austin Zheng  wrote:
>>>
>>> How so? I'm interested in anything that can get us away from having to
>>> generating code at compile-time.
>>>
>>> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic <
>>> laurent.mihalko...@gmail.com> wrote:
>>>

 What's interesting about the code in the manifesto is that it looks
 very much like "..." is a runtime construct, as opposed to trying the get
 the compiler to do the heavy lifting.

>>>
>>>
>>> ___

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Xiaodi Wu via swift-evolution]

On Tue, May 31, 2016 at 3:16 PM, Brandon Knope  wrote:

> And why couldn't we propose that it should?
>

And that is this proposal; the options considered for the spelling are
comma, semicolon, and `&&`.

Now we circle back to my earlier point. The introduction of any of these
would argue for the elimination of `where`, for the reasons I've stated
above. Briefly, everything that can be expressed using `where` could be
expressed using the comma, semicolon, or `&&`. Since there is no good way
to enforce the semantic relationship requirement for `where`, only a proxy
rule about variable names can be contemplated, which as I've demonstrated
is ineffective.

If you're asking why commas or semicolons have been proposed instead of
`&&`, that argument has been made above by others.


Brandon
>
> On May 31, 2016, at 4:14 PM, Xiaodi Wu  wrote:
>
> On Tue, May 31, 2016 at 3:08 PM, Brandon Knope  wrote:
>
>> What is wrong with:
>>
>> if let y = y && x < z
>>
>> They are, after all, independent from each other.
>>
>
> That won't compile.
>
>
> Brandon
>>
>> On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution
>>  wrote:
>>
>>>
>>> On May 31, 2016, at 1:47 PM, Xiaodi Wu  wrote:
>>>
>>>
>>>
>>> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution
>>>  wrote:
>>>

> Not allowed:
> …
> let a = a
> let b = b where b > 10 && a > 5
>

 Why would this not be allowed by your rule? You're making use of `b` in
 your where clause. As I demonstrated above, essentially any assertion can
 be rewritten to work around your rule. In general:


 It is not allowed because  ‘a’ is defined in the line above. It must be
 defined in the ‘if let’ associated with the where in which it is mentioned.

>>>
>>> That's a much more restrictive where clause than you proposed earlier.
>>> You'd not be able to write:
>>>
>>> ```
>>> let b = b where b > anyOtherVariable
>>> ```
>>>
>>>
>>> The definition is not a formal one, but that was the intent.
>>>
>>> ```
>>> let b = b where b > anyOtherVariable
>>> ```
>>>
>>> is legal as long as `anyOtherVariable` is not defined within the entire
>>> condition clause
>>>
>>
>>
>> You can propose that rule, but it doesn't solve the issue. If, today,
>> I've got
>>
>> ```
>> let x = 1
>> let y: Int? = 2
>> let z = 3
>>
>> if let y = y where x < z {
>>   // do stuff
>> }
>> ```
>>
>> your rule simply forces
>>
>> ```
>> if let y = y where y == y && x < z {
>>   // do stuff
>> }
>> ```
>>
>> The point is, the semantic relationship between what comes before and
>> after `where` exists in the mind of the human reader only.
>>
>> ___
>> 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] Variadic generics discussion

[Austin Zheng via swift-evolution]

I have a proposal for #6 in the pipe, but there are actually some
subtleties I have to work out (it's not as simple as just slapping a
generic type signature on a let constant).

I think #5 is just considered a 'bug' and doesn't need a proposal (it might
actually be finished already; I saw some commits recently); same with #4.
#7 is not very useful without variadic generics (it pretty much exists to
allow tuples to conform to protocols, and tuples are inherently variadic).

I wanted to take a stab at #2. The core team has talked so much about #1
that I'd be surprised if they don't already have an idea as to how they
want to do it, plus it's complicated for a number of reasons to get right.
In such a case having the community push forward an alternate proposal
would just be giving everyone more unneeded work.

#3 seems semantically straightforward. AFAIK there's nothing a subscript
can do that a getter and setter method can't do together, and methods can
already be generic. A proposal shouldn't be hard to put together.

Let me know your thoughts.

Best,
Austin




On Tue, May 31, 2016 at 1:16 PM, Matthew Johnson 
wrote:

>
> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is pretty much where my thinking about the topic has led me as well.
> I'll resign this topic to pursue some other, hopefully more relevant work,
> although anyone who wants to continue the discussion is welcome to.
>
>
> Seems reasonable to wait until we can at least evaluate the macro approach
> properly.
>
> Are you planning to continue work on generics?  FWIW, my top priority list
> for items without proposals is roughly:
>
> 1. Conditional conformance (
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-
> )
> 2. Parameterized extensions (
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions
> )
> 3. Generic subscripts (
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts
> )
> 4. Recursive protocol constraints (
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics
> )
> 5. Nested generics (
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics
> )
> 6. Default generic arguments (
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-generic-arguments
> )
> 7. Extensions of structural types (
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
> )
>
> And this one seems like low hanging fruit:
>
> Default implementations in protocols (
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols-
> )
>
> How does this compare to your priorities for generics?
>
>
> On Tue, May 31, 2016 at 12:49 PM, Chris Lattner 
> wrote:
>
>>
>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> well there is no macro system, and for the moment a clear statement from
>> chris that this is not on the table in the short term. the code in the
>> example looked like run-of-the-mill swift, except for the “…". so that
>> leaves us with swift looking code that would be executed by the compiler,
>> but with nothing particular to tell which parts to and which not. just a
>> thought.
>>
>>
>> Lets be clear though: variadic generics are not in scope for Swift 3
>> either.
>>
>> I definitely don’t speak for the rest of the core team, nor have I
>> discussed it with them…  but IMO, this whole feature seems like a better
>> fit for a macro system than it does to complicate the generics system.
>> Unlike C++’s template system, our generics system inherently has runtime /
>> dynamic dispatch properties, and I don’t think that shoehorning variadics
>> into it is going to work out well.
>>
>> -Chris
>>
>>
>>
>> On May 31, 2016, at 7:59 PM, Austin Zheng  wrote:
>>
>> How so? I'm interested in anything that can get us away from having to
>> generating code at compile-time.
>>
>> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic <
>> laurent.mihalko...@gmail.com> wrote:
>>
>>>
>>> What's interesting about the code in the manifesto is that it looks very
>>> much like "..." is a runtime construct, as opposed to trying the get the
>>> compiler to do the heavy lifting.
>>>
>>
>>
>> ___
>> 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 `return` optional in computed properties for a single case

[Adrian Zubarev via swift-evolution]

I added the example I posted in my last reply and submitted a pull request. 



-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

[David Rönnqvist via swift-evolution]

> 31 maj 2016 kl. 21:37 skrev Chris Lattner :
> 
>> On May 31, 2016, at 6:32 AM, David Rönnqvist via swift-evolution 
>>  wrote:
>> Lazy evaluation when assigning static variables
>> Introduction
>> Both stored type properties (static) and lazy stored properties (lazy var) 
>> are lazily initialized. However, they have different initialization behavior 
>> in that stored type properties evaluate even when assigning them a new value.
>> 
>> The following code will print "static", but not "lazy":
>> 
>> class Foo {
>> static var bar: String = {
>> print("static")
>> return "Default"
>> }()
>> 
>> lazy var baz: String = {
>> print("lazy")
>> return "Lazy"
>> }()
>> }
>> 
>> Foo.bar = "Set" // this evaluates the initial value of `bar` before setting 
>> a new value
>> 
>> let foo = Foo()
>> foo.baz = "Set" // this doesn't evaluate `baz` before setting a new value
> This seems like a step in the right direction, but may not big a step far 
> enough.  Keep in mind that “static” and global variables are quite different 
> than lazy variables, both in terms of implementation and behavior but also in 
> terms of planned future direction.
> 
> “lazy” is almost certainly to be replaced by property behaviors in the 
> future, making them a library defined feature whose behavior can be changed 
> arbitrarily, and can hopefully have useful additional functionality like a 
> “reset()” method added to them.  Global variables are currently not like 
> that: their behavior is defined by compiler magic instead of by property 
> semantics.
> 
> If the goal was to remove magic from the compiler, then a possible direction 
> would be to do something like:
> 
> 1) Introduce a new declmodifier named something like “atomiclazy”.
> 2) Disallow global and static variables, unless they are explicitly marked 
> atomiclazy (compiler would provide a fixit hint to suggest this).
> 3) Replace the atomiclazy magic with a property behavior when they exist.
> 
> In this model, you’d presumably have the choice about atomiclazy or lazy when 
> setting up either a static or a local property.
> 
> -Chris
> 

Did I understand it correctly that, under such a proposal, there would be no 
compiler magic for global properties and instead both global, type, and 
instance properties would be controlled by property behaviors (or 
lazy/atomiclazy until they are replaced by property behaviors)?

`lazy` having he current a behavior of lazy properties (no threading 
guarantees, not evaluating on assignment),
`atomiclazy` having the current behavior of static properties (guaranteed to 
only evaluate once when accessed from multiple threads, evaluating even on 
assignment)

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

Re: [swift-evolution] Variadic generics discussion

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 2:56 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> This is pretty much where my thinking about the topic has led me as well. 
> I'll resign this topic to pursue some other, hopefully more relevant work, 
> although anyone who wants to continue the discussion is welcome to.

Seems reasonable to wait until we can at least evaluate the macro approach 
properly.

Are you planning to continue work on generics?  FWIW, my top priority list for 
items without proposals is roughly:

1. Conditional conformance 
(https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-
 
)
2. Parameterized extensions 
(https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#parameterized-extensions
 
)
3. Generic subscripts 
(https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts
 
)
4. Recursive protocol constraints 
(https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics
 
)
5. Nested generics 
(https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#nested-generics
 
)
6. Default generic arguments 
(https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-generic-arguments
 
)
7. Extensions of structural types 
(https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types
 
)

And this one seems like low hanging fruit:

Default implementations in protocols 
(https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#default-implementations-in-protocols-
 
)

How does this compare to your priorities for generics?

> 
> On Tue, May 31, 2016 at 12:49 PM, Chris Lattner  > wrote:
> 
>> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution 
>> > wrote:
>> 
>> well there is no macro system, and for the moment a clear statement from 
>> chris that this is not on the table in the short term. the code in the 
>> example looked like run-of-the-mill swift, except for the “…". so that 
>> leaves us with swift looking code that would be executed by the compiler, 
>> but with nothing particular to tell which parts to and which not. just a 
>> thought.
> 
> Lets be clear though: variadic generics are not in scope for Swift 3 either.  
> 
> I definitely don’t speak for the rest of the core team, nor have I discussed 
> it with them…  but IMO, this whole feature seems like a better fit for a 
> macro system than it does to complicate the generics system.  Unlike C++’s 
> template system, our generics system inherently has runtime / dynamic 
> dispatch properties, and I don’t think that shoehorning variadics into it is 
> going to work out well.
> 
> -Chris
> 
>> 
>> 
>>> On May 31, 2016, at 7:59 PM, Austin Zheng >> > wrote:
>>> 
>>> How so? I'm interested in anything that can get us away from having to 
>>> generating code at compile-time.
>>> 
>>> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic 
>>> > wrote:
>>> 
>>> What's interesting about the code in the manifesto is that it looks very 
>>> much like "..." is a runtime construct, as opposed to trying the get the 
>>> compiler to do the heavy lifting.
>>> 
>> 
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Brandon Knope via swift-evolution]

And why couldn't we propose that it should?

Brandon 

> On May 31, 2016, at 4:14 PM, Xiaodi Wu  wrote:
> 
>> On Tue, May 31, 2016 at 3:08 PM, Brandon Knope  wrote:
>> What is wrong with:
>> 
>> if let y = y && x < z
>> 
>> They are, after all, independent from each other.
> 
> That won't compile.
>  
> 
>> Brandon 
>> 
>>> On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution 
  wrote:
>>> 
 
> On May 31, 2016, at 1:47 PM, Xiaodi Wu  wrote:
> 
> 
> 
> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution 
>  wrote:
 
 Not allowed:
 …
 let a = a
 let b = b where b > 10 && a > 5
>>> 
>>> Why would this not be allowed by your rule? You're making use of `b` in 
>>> your where clause. As I demonstrated above, essentially any assertion 
>>> can be rewritten to work around your rule. In general:
>> 
>> It is not allowed because  ‘a’ is defined in the line above. It must be 
>> defined in the ‘if let’ associated with the where in which it is 
>> mentioned.
> 
> That's a much more restrictive where clause than you proposed earlier. 
> You'd not be able to write:
> 
> ```
> let b = b where b > anyOtherVariable
> ```
 
 
 The definition is not a formal one, but that was the intent.
 
 ```
 let b = b where b > anyOtherVariable
 ```
 is legal as long as `anyOtherVariable` is not defined within the entire 
 condition clause
>>> 
>>> 
>>> You can propose that rule, but it doesn't solve the issue. If, today, I've 
>>> got
>>> 
>>> ```
>>> let x = 1
>>> let y: Int? = 2
>>> let z = 3
>>> 
>>> if let y = y where x < z {
>>>   // do stuff
>>> }
>>> ```
>>> 
>>> your rule simply forces
>>> 
>>> ```
>>> if let y = y where y == y && x < z {
>>>   // do stuff
>>> }
>>> ```
>>> 
>>> The point is, the semantic relationship between what comes before and after 
>>> `where` exists in the mind of the human reader only.
>>> 
>>> ___
>>> 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-0099: Restructuring Condition Clauses

[Brandon Knope via swift-evolution]

What is wrong with:

if let x = x where x > 10, y != 5, let z = z where z != x

Just as a contrived example?

Brandon 

> On May 31, 2016, at 4:03 PM, Xiaodi Wu  wrote:
> 
>> On Tue, May 31, 2016 at 2:59 PM, Brandon Knope  wrote:
>> Except "b" is the main focus of the where clause and b was just in the 
>> preceding if condition. 
>> 
>> I feel like we are trying to find ways to break the current where clause 
>> even though we've enjoyed it for almost a year now. I had no idea it was 
>> problematic and restrictive. I thought it made its intent very 
>> clear...leading to very readable code. 
>> 
>> Pretty soon almost every construct but conditionals will be allowed to have 
>> where clauses, and THAT seems inconsistent to me. 
>> 
>> ...what exactly is the current problem? Can someone show me a real world 
>> example?? I've already forgotten it in all of this discussion -_-
> 
> The origin of the problem is a simple question: how does one test for 
> something unrelated to the variable that's bound in an `if let` statement? 
> The answer is: in today's Swift, any such test after the first `let` must 
> come after `where`. This is problematic and restrictive because one is forced 
> to imply a semantic relationship that doesn't exist.
>  
>> Brandon 
>> 
>>> On May 31, 2016, at 3:47 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution 
>>>  wrote:
>> 
>> Not allowed:
>> …
>> let a = a
>> let b = b where b > 10 && a > 5
> 
> Why would this not be allowed by your rule? You're making use of `b` in 
> your where clause. As I demonstrated above, essentially any assertion can 
> be rewritten to work around your rule. In general:
 
 It is not allowed because  ‘a’ is defined in the line above. It must be 
 defined in the ‘if let’ associated with the where in which it is mentioned.
>>> 
>>> That's a much more restrictive where clause than you proposed earlier. 
>>> You'd not be able to write:
>>> 
>>> ```
>>> let b = b where b > anyOtherVariable
>>> ``` 
>>> 
>>> ___
>>> 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 `return` optional in computed properties for a single case

[Vladimir.S via swift-evolution]

On 31.05.2016 22:42, Leonardo Pessoa via swift-evolution wrote:

I'd actually like to see a change in guard so that I don't need those
braces. I'd like something more readable like

|   guard cond1 or return nil
|   guard cond2 or throw MyError.IllegalValue
|   guard cond3 or do { ... }


I partially support this, but don't like this 'or'..
For me 'otherwise' or 'else' is better, but as soon as braces after `else` 
is required in `if` statement, for `guard` we need another word to be able 
to omit braces...


guard cond otherwise return
guard cond otherwise return nil
guard cond otherwise throw MyError.IllegalValue
guard cond otherwise do { ... }

But I feel like this will be inconsistent with other parts of language, 
like `if` (don't you want to be able to do `if cond return nil`?), so I 
don't think it's worth to discuss this.


Hmm.. just as thought experiment :

if cond return nil else do {...}

if cond do {...} else return nil

if cond throw MyError.IllegalValue else return nil

if cond do {...} else do {...}



It may add more cases for the compiler to handle but in all cases I
used guard so far the block was never really needed. But I think this
is out of the scope of this thread.

L

On 31 May 2016 at 15:59, Adrian Zubarev via swift-evolution
 wrote:

+1. This is example *is not* a single expression code block. There are 3
expressions (the condition, the return value in the else block, and the
primary return value).

The `else` block is a returning single expression block. I can’t show the
`guard` example without any returning scope.

You said it yourself "everywhere in the language“. It’s not “everywhere“ if
we would left out `guards` else-returning block.

If we’d allow this we could also write:

func test(boolean: Bool) {
guard boolean else {}
print("true")
}

This is useless and less readable.

But we already can do this with closures:

let nop = {} // useless

switch value {
   ...
   default: {}() // do nothing
}

--
Adrian Zubarev
Sent with Airmail


___
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] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Xiaodi Wu via swift-evolution]

On Tue, May 31, 2016 at 3:08 PM, Brandon Knope  wrote:

> What is wrong with:
>
> if let y = y && x < z
>
> They are, after all, independent from each other.
>

That won't compile.


Brandon
>
> On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On May 31, 2016, at 1:47 PM, Xiaodi Wu  wrote:
>>
>>
>>
>> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution
>>  wrote:
>>
>>>
 Not allowed:
 …
 let a = a
 let b = b where b > 10 && a > 5

>>>
>>> Why would this not be allowed by your rule? You're making use of `b` in
>>> your where clause. As I demonstrated above, essentially any assertion can
>>> be rewritten to work around your rule. In general:
>>>
>>>
>>> It is not allowed because  ‘a’ is defined in the line above. It must be
>>> defined in the ‘if let’ associated with the where in which it is mentioned.
>>>
>>
>> That's a much more restrictive where clause than you proposed earlier.
>> You'd not be able to write:
>>
>> ```
>> let b = b where b > anyOtherVariable
>> ```
>>
>>
>> The definition is not a formal one, but that was the intent.
>>
>> ```
>> let b = b where b > anyOtherVariable
>> ```
>>
>> is legal as long as `anyOtherVariable` is not defined within the entire
>> condition clause
>>
>
>
> You can propose that rule, but it doesn't solve the issue. If, today, I've
> got
>
> ```
> let x = 1
> let y: Int? = 2
> let z = 3
>
> if let y = y where x < z {
>   // do stuff
> }
> ```
>
> your rule simply forces
>
> ```
> if let y = y where y == y && x < z {
>   // do stuff
> }
> ```
>
> The point is, the semantic relationship between what comes before and
> after `where` exists in the mind of the human reader only.
>
> ___
> 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-0099: Restructuring Condition Clauses

[Christopher Kornher via swift-evolution]

> On May 31, 2016, at 1:59 PM, Brandon Knope  wrote:
> 
> Except "b" is the main focus of the where clause and b was just in the 
> preceding if condition. 
> 
> I feel like we are trying to find ways to break the current where clause even 
> though we've enjoyed it for almost a year now. I had no idea it was 
> problematic and restrictive. I thought it made its intent very 
> clear...leading to very readable code. 
> 
> Pretty soon almost every construct but conditionals will be allowed to have 
> where clauses, and THAT seems inconsistent to me. 
> 
> ...what exactly is the current problem? Can someone show me a real world 
> example?? I've already forgotten it in all of this discussion -_-
> 
> Brandon 
> 

I did this to explore why many people are reluctant to give-up ‘where’. The use 
of ‘where' seems intuitive to mess well, and I did not understand why. It seems 
to natural group all logic concerning a constant with its definition and this 
seems to be a way to do that.

These rules add restrictions, but it does group related elements.  I am not 
convinced that this improves the language, but I though that it was worth 
exploring.  


> On May 31, 2016, at 3:47 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> 
>> 
>> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution 
>> > wrote:
>>> 
>>> Not allowed:
>>> …
>>> let a = a
>>> let b = b where b > 10 && a > 5
>>> 
>>> Why would this not be allowed by your rule? You're making use of `b` in 
>>> your where clause. As I demonstrated above, essentially any assertion can 
>>> be rewritten to work around your rule. In general:
>> 
>> It is not allowed because  ‘a’ is defined in the line above. It must be 
>> defined in the ‘if let’ associated with the where in which it is mentioned.
>> 
>> That's a much more restrictive where clause than you proposed earlier. You'd 
>> not be able to write:
>> 
>> ```
>> let b = b where b > anyOtherVariable
>> ``` 
>> 
>> ___
>> 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-0099: Restructuring Condition Clauses

[Brandon Knope via swift-evolution]

The y == y I presume is to get around this requirement by reintroducing a 
variable in the previous part of the conditional to be able to refer to other 
variables. 

x > z isn't allowed, but y == y && x > z would be because it's using y. 

I'm not convinced anyone would do this when they could just && x > z anyways 

Brandon 

> On May 31, 2016, at 4:06 PM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> I should have left the entire context in my reply.
> 
> 
>> On May 31, 2016, at 1:59 PM, Xiaodi Wu  wrote:
>> 
>>> On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution 
>>>  wrote:
>> 
>>> 
 On May 31, 2016, at 1:47 PM, Xiaodi Wu  wrote:
 
 
 
 On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution 
  wrote:
>>> 
>>> Not allowed:
>>> …
>>> let a = a
>>> let b = b where b > 10 && a > 5
>> 
>> Why would this not be allowed by your rule? You're making use of `b` in 
>> your where clause. As I demonstrated above, essentially any assertion 
>> can be rewritten to work around your rule. In general:
> 
> It is not allowed because  ‘a’ is defined in the line above. It must be 
> defined in the ‘if let’ associated with the where in which it is 
> mentioned.
 
 That's a much more restrictive where clause than you proposed earlier. 
 You'd not be able to write:
 
 ```
 let b = b where b > anyOtherVariable
 ```
>>> 
>>> 
>>> The definition is not a formal one, but that was the intent.
>>> 
>>> ```
>>> let b = b where b > anyOtherVariable
>>> ```
>>> is legal as long as `anyOtherVariable` is not defined within the entire 
>>> condition clause
>> 
>> 
>> You can propose that rule, but it doesn't solve the issue. If, today, I've 
>> got
>> 
>> ```
>> let x = 1
>> let y: Int? = 2
>> let z = 3
>> 
>> if let y = y where x < z {
>>   // do stuff
>> }
>> ```
>> 
>> your rule simply forces
>> 
>> ```
>> if let y = y where y == y && x < z {
>>   // do stuff
>> }
>> ```
>> 
>> The point is, the semantic relationship between what comes before and after 
>> `where` exists in the mind of the human reader only.
> 
> I meant to add that all boolean expressions after the where must use one of 
> the constants defined in the associated `if let` so the `&& x < z` would not 
> be allowed.
> 
> I don’t understand the 'y == y’ in your example
> 
> 
> ___
> 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-0099: Restructuring Condition Clauses

[Brandon Knope via swift-evolution]

What is wrong with:

if let y = y && x < z

They are, after all, independent from each other. 

Brandon 

> On May 31, 2016, at 3:59 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution 
>>  wrote:
> 
>> 
>>> On May 31, 2016, at 1:47 PM, Xiaodi Wu  wrote:
>>> 
>>> 
>>> 
>>> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution 
>>>  wrote:
>> 
>> Not allowed:
>> …
>> let a = a
>> let b = b where b > 10 && a > 5
> 
> Why would this not be allowed by your rule? You're making use of `b` in 
> your where clause. As I demonstrated above, essentially any assertion can 
> be rewritten to work around your rule. In general:
 
 It is not allowed because  ‘a’ is defined in the line above. It must be 
 defined in the ‘if let’ associated with the where in which it is mentioned.
>>> 
>>> That's a much more restrictive where clause than you proposed earlier. 
>>> You'd not be able to write:
>>> 
>>> ```
>>> let b = b where b > anyOtherVariable
>>> ```
>> 
>> 
>> The definition is not a formal one, but that was the intent.
>> 
>> ```
>> let b = b where b > anyOtherVariable
>> ```
>> is legal as long as `anyOtherVariable` is not defined within the entire 
>> condition clause
> 
> 
> You can propose that rule, but it doesn't solve the issue. If, today, I've got
> 
> ```
> let x = 1
> let y: Int? = 2
> let z = 3
> 
> if let y = y where x < z {
>   // do stuff
> }
> ```
> 
> your rule simply forces
> 
> ```
> if let y = y where y == y && x < z {
>   // do stuff
> }
> ```
> 
> The point is, the semantic relationship between what comes before and after 
> `where` exists in the mind of the human reader only.
> 
> ___
> 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-0099: Restructuring Condition Clauses

[Xiaodi Wu via swift-evolution]

On Tue, May 31, 2016 at 2:59 PM, Brandon Knope  wrote:

> Except "b" is the main focus of the where clause and b was just in the
> preceding if condition.
>
> I feel like we are trying to find ways to break the current where clause
> even though we've enjoyed it for almost a year now. I had no idea it was
> problematic and restrictive. I thought it made its intent very
> clear...leading to very readable code.
>
> Pretty soon almost every construct but conditionals will be allowed to
> have where clauses, and THAT seems inconsistent to me.
>
> ...what exactly is the current problem? Can someone show me a real world
> example?? I've already forgotten it in all of this discussion -_-
>
>
The origin of the problem is a simple question: how does one test for
something unrelated to the variable that's bound in an `if let` statement?
The answer is: in today's Swift, any such test after the first `let` must
come after `where`. This is problematic and restrictive because one is
forced to imply a semantic relationship that doesn't exist.


> Brandon
>
> On May 31, 2016, at 3:47 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>> Not allowed:
>>> …
>>> let a = a
>>> let b = b where b > 10 && a > 5
>>>
>>
>> Why would this not be allowed by your rule? You're making use of `b` in
>> your where clause. As I demonstrated above, essentially any assertion can
>> be rewritten to work around your rule. In general:
>>
>>
>> It is not allowed because  ‘a’ is defined in the line above. It must be
>> defined in the ‘if let’ associated with the where in which it is mentioned.
>>
>
> That's a much more restrictive where clause than you proposed earlier.
> You'd not be able to write:
>
> ```
> let b = b where b > anyOtherVariable
> ```
>
> ___
> 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-0099: Restructuring Condition Clauses

[Xiaodi Wu via swift-evolution]

On Tue, May 31, 2016 at 2:51 PM, Christopher Kornher via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On May 31, 2016, at 1:47 PM, Xiaodi Wu  wrote:
>
>
>
> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>> Not allowed:
>>> …
>>> let a = a
>>> let b = b where b > 10 && a > 5
>>>
>>
>> Why would this not be allowed by your rule? You're making use of `b` in
>> your where clause. As I demonstrated above, essentially any assertion can
>> be rewritten to work around your rule. In general:
>>
>>
>> It is not allowed because  ‘a’ is defined in the line above. It must be
>> defined in the ‘if let’ associated with the where in which it is mentioned.
>>
>
> That's a much more restrictive where clause than you proposed earlier.
> You'd not be able to write:
>
> ```
> let b = b where b > anyOtherVariable
> ```
>
>
> The definition is not a formal one, but that was the intent.
>
> ```
> let b = b where b > anyOtherVariable
> ```
>
> is legal as long as `anyOtherVariable` is not defined within the entire
> condition clause
>


You can propose that rule, but it doesn't solve the issue. If, today, I've
got

```
let x = 1
let y: Int? = 2
let z = 3

if let y = y where x < z {
  // do stuff
}
```

your rule simply forces

```
if let y = y where y == y && x < z {
  // do stuff
}
```

The point is, the semantic relationship between what comes before and after
`where` exists in the mind of the human reader only.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Brandon Knope via swift-evolution]

Except "b" is the main focus of the where clause and b was just in the 
preceding if condition. 

I feel like we are trying to find ways to break the current where clause even 
though we've enjoyed it for almost a year now. I had no idea it was problematic 
and restrictive. I thought it made its intent very clear...leading to very 
readable code. 

Pretty soon almost every construct but conditionals will be allowed to have 
where clauses, and THAT seems inconsistent to me. 

...what exactly is the current problem? Can someone show me a real world 
example?? I've already forgotten it in all of this discussion -_-

Brandon 

> On May 31, 2016, at 3:47 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> 
> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution 
>  wrote:
 
 Not allowed:
 …
 let a = a
 let b = b where b > 10 && a > 5
>>> 
>>> Why would this not be allowed by your rule? You're making use of `b` in 
>>> your where clause. As I demonstrated above, essentially any assertion can 
>>> be rewritten to work around your rule. In general:
>> 
>> It is not allowed because  ‘a’ is defined in the line above. It must be 
>> defined in the ‘if let’ associated with the where in which it is mentioned.
> 
> That's a much more restrictive where clause than you proposed earlier. You'd 
> not be able to write:
> 
> ```
> let b = b where b > anyOtherVariable
> ``` 
> 
> ___
> 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 `return` optional in computed properties for a single case

[Adrian Zubarev via swift-evolution]

I apologize for the tons of typos I make. :/



-- 
Adrian Zubarev
Sent with Airmail

Am 31. Mai 2016 um 21:55:53, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

I'd actually like to see a change in guard so that I don't need those 
braces. I'd like something more readable like 

| guard cond1 or return nil 
| guard cond2 or throw MyError.IllegalValue 
| guard cond3 or do { ... } 

It may add more cases for the compiler to handle but in all cases I 
used guard so far the block was never really needed. But I think this 
is out of the scope of this thread. 
This is a different topic, because it would create an alternative for a 
single-expression guard-else-block. ;)

That looks good.  You might want to include more complex expressions just to 
make it clear that this isn’t limited to literal-returning expressions.  
Otherwise I think it covers it.  Thanks for putting this together!  I’ve wanted 
this for a long time… :)
Is this example enough for you, what do you thing?

// Today:
public struct Character {
  
private let _pointer: UnsafePointer
public let source: Module.Source
public var value: Swift.Character {
return self._pointer.memory
}
...
}

// Rewritten:
public struct Character {
...
public var value: Swift.Character { self._pointer.memory }
...
}

-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

[Charles Srstka via swift-evolution]

A huge +1 on the syntax change, which I think is a colossal improvement over 
the current situation and adds a lot of clarity to enum declarations.

Neutral on the necessity to add actual stored properties to the enums. If the 
new syntax were merely syntactic sugar that would effectively generate the 
switch statements behind the scenes, that would work for me too, and would 
probably offend fewer people.

Charles

> On May 31, 2016, at 9:17 AM, Jānis Kiršteins via swift-evolution 
>  wrote:
> 
> I wrote a proposal draft:
> 
> # Enum case stored properties
> 
> * Proposal: TBD
> * Author: [Janis Kirsteins](https://github.com/kirsteins)
> * Status: TBD
> * Review manager: TBD
> 
> ## Introduction
> 
> This proposal allows each enum case to have stored properties.
> 
> ## Motivation
> 
> Enums cases can have a lot of constant (or variable) static values
> associated with it. For example, planets can have mass, radius, age,
> closest star etc. Currently there is no way to set or get those values
> easily.
> 
> Example below shows that is hard to read and manage static associated
> values with each case. It is hard to add or remove case as it would
> require to add or remove code in four different places in file. Also
> static associated value like `UIBezierPath` is recreated each time the
> property is computed while it's constant.
> 
> ```swift
> enum Suit {
>case spades
>case hearts
>case diamonds
>case clubs
> 
>var simpleDescription: String {
>switch self {
>case .spades:
>return "spades"
>case .hearts:
>return "hearts"
>case .diamonds:
>return "diamonds"
>case .clubs:
>return "clubs"
>}
>}
> 
>var color: UIColor {
>switch self {
>case .spades:
>return .blackColor()
>case .hearts:
>return .redColor()
>case .diamonds:
>return .redColor()
>case .clubs:
>return .blackColor()
>}
>}
> 
>var symbol: String {
>switch self {
>case .spades:
>return "♠"
>case .hearts:
>return "♥"
>case .diamonds:
>return "♦"
>case .clubs:
>return "♣"
>}
>}
> 
>var bezierPath: UIBezierPath {
>switch self {
>case .spades:
>let path = UIBezierPath()
>// omitted lines ...
>return path
>case .hearts:
>let path = UIBezierPath()
>// omitted lines ...
>return path
>case .diamonds:
>let path = UIBezierPath()
>// omitted lines ...
>return path
>case .clubs:
>let path = UIBezierPath()
>// omitted lines ...
>return path
>}
>}
> }
> ```
> 
> ## Proposed solution
> 
> Support stored properties for enum cases just as each case were an
> instance. Case properties are initialized block after each case
> declaration.
> 
> ```swift
> enum Suit {
>let simpleDescription: String
>let color: UIColor
>let symbol: String
>let bezierPath: UIBezierPath
> 
>case spades {
>simpleDescription = "spades"
>color = .blackColor()
>symbol = "♠"
>let bezierPath = UIBezierPath()
>// omitted lines ...
>self.bezierPath = bezierPath
>}
> 
>case hearts {
>simpleDescription = "hearts"
>color = .redColor()
>symbol = "♥"
>let bezierPath = UIBezierPath()
>// omitted lines ...
>self.bezierPath = bezierPath
>}
> 
>case diamonds {
>simpleDescription = "diamonds"
>color = .redColor()
>symbol = "♦"
>let bezierPath = UIBezierPath()
>// omitted lines ...
>self.bezierPath = bezierPath
>}
> 
>case clubs {
>simpleDescription = "clubs"
>color = .blackColor()
>symbol = "♣"
>let bezierPath = UIBezierPath()
>// omitted lines ...
>self.bezierPath = bezierPath
>}
> }
> 
> let symbol = Suit.spades.symbol // "♠"
> ```
> 
> The proposed solution improves:
> - Readability as cases are closer with their related data;
> - Improves code maintainability as a case can be removed or added in one 
> place;
> - Improved performance as there is no need to recreate static values;
> - ~30% less lines of code in given example.
> 
> ## Detailed design
> 
>  Stored properties
> 
> Enum stored properties are supported the same way they are supported
> for structs can classes. Unlike enum associated values, stored
> properties are static to case and are shared for the same case.
> 
> Properties are accessed:
> ```swift
> let simpleDescription = Suit.spades.simpleDescription
> ```
> 
> Mutable properties can be set:
> ```swift
> Suit.spades.simpleDescription = "new simple description"
> ```
> 
>  Initialization
> 
> If enum 

Re: [swift-evolution] Variadic generics discussion

[Austin Zheng via swift-evolution]

This is pretty much where my thinking about the topic has led me as well.
I'll resign this topic to pursue some other, hopefully more relevant work,
although anyone who wants to continue the discussion is welcome to.

On Tue, May 31, 2016 at 12:49 PM, Chris Lattner  wrote:

>
> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> well there is no macro system, and for the moment a clear statement from
> chris that this is not on the table in the short term. the code in the
> example looked like run-of-the-mill swift, except for the “…". so that
> leaves us with swift looking code that would be executed by the compiler,
> but with nothing particular to tell which parts to and which not. just a
> thought.
>
>
> Lets be clear though: variadic generics are not in scope for Swift 3
> either.
>
> I definitely don’t speak for the rest of the core team, nor have I
> discussed it with them…  but IMO, this whole feature seems like a better
> fit for a macro system than it does to complicate the generics system.
> Unlike C++’s template system, our generics system inherently has runtime /
> dynamic dispatch properties, and I don’t think that shoehorning variadics
> into it is going to work out well.
>
> -Chris
>
>
>
> On May 31, 2016, at 7:59 PM, Austin Zheng  wrote:
>
> How so? I'm interested in anything that can get us away from having to
> generating code at compile-time.
>
> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic <
> laurent.mihalko...@gmail.com> wrote:
>
>>
>> What's interesting about the code in the manifesto is that it looks very
>> much like "..." is a runtime construct, as opposed to trying the get the
>> compiler to do the heavy lifting.
>>
>
>
> ___
> 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-0099: Restructuring Condition Clauses

[Christopher Kornher via swift-evolution]

> On May 31, 2016, at 1:47 PM, Xiaodi Wu  wrote:
> 
> 
> 
> On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution 
> > wrote:
>> 
>> Not allowed:
>> …
>> let a = a
>> let b = b where b > 10 && a > 5
>> 
>> Why would this not be allowed by your rule? You're making use of `b` in your 
>> where clause. As I demonstrated above, essentially any assertion can be 
>> rewritten to work around your rule. In general:
> 
> It is not allowed because  ‘a’ is defined in the line above. It must be 
> defined in the ‘if let’ associated with the where in which it is mentioned.
> 
> That's a much more restrictive where clause than you proposed earlier. You'd 
> not be able to write:
> 
> ```
> let b = b where b > anyOtherVariable
> ```


The definition is not a formal one, but that was the intent.

```
let b = b where b > anyOtherVariable
```
is legal as long as `anyOtherVariable` is not defined within the entire 
condition clause


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

Re: [swift-evolution] Variadic generics discussion

[Chris Lattner via swift-evolution]

> On May 31, 2016, at 12:17 PM, L Mihalkovic via swift-evolution 
>  wrote:
> 
> well there is no macro system, and for the moment a clear statement from 
> chris that this is not on the table in the short term. the code in the 
> example looked like run-of-the-mill swift, except for the “…". so that leaves 
> us with swift looking code that would be executed by the compiler, but with 
> nothing particular to tell which parts to and which not. just a thought.

Lets be clear though: variadic generics are not in scope for Swift 3 either.  

I definitely don’t speak for the rest of the core team, nor have I discussed it 
with them…  but IMO, this whole feature seems like a better fit for a macro 
system than it does to complicate the generics system.  Unlike C++’s template 
system, our generics system inherently has runtime / dynamic dispatch 
properties, and I don’t think that shoehorning variadics into it is going to 
work out well.

-Chris

> 
> 
>> On May 31, 2016, at 7:59 PM, Austin Zheng > > wrote:
>> 
>> How so? I'm interested in anything that can get us away from having to 
>> generating code at compile-time.
>> 
>> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic 
>> > wrote:
>> 
>> What's interesting about the code in the manifesto is that it looks very 
>> much like "..." is a runtime construct, as opposed to trying the get the 
>> compiler to do the heavy lifting.
>> 
> 
> ___
> 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-0099: Restructuring Condition Clauses

[Xiaodi Wu via swift-evolution]

On Tue, May 31, 2016 at 2:45 PM, Christopher Kornher via swift-evolution <
swift-evolution@swift.org> wrote:

>
>> Not allowed:
>> …
>> let a = a
>> let b = b where b > 10 && a > 5
>>
>
> Why would this not be allowed by your rule? You're making use of `b` in
> your where clause. As I demonstrated above, essentially any assertion can
> be rewritten to work around your rule. In general:
>
>
> It is not allowed because  ‘a’ is defined in the line above. It must be
> defined in the ‘if let’ associated with the where in which it is mentioned.
>

That's a much more restrictive where clause than you proposed earlier.
You'd not be able to write:

```
let b = b where b > anyOtherVariable
```
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Christopher Kornher via swift-evolution]

> 
> Not allowed:
> …
> let a = a
> let b = b where b > 10 && a > 5
> 
> Why would this not be allowed by your rule? You're making use of `b` in your 
> where clause. As I demonstrated above, essentially any assertion can be 
> rewritten to work around your rule. In general:

It is not allowed because  ‘a’ is defined in the line above. It must be defined 
in the ‘if let’ associated with the where in which it is mentioned.


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

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Leonardo Pessoa via swift-evolution]

I'd actually like to see a change in guard so that I don't need those
braces. I'd like something more readable like

|   guard cond1 or return nil
|   guard cond2 or throw MyError.IllegalValue
|   guard cond3 or do { ... }

It may add more cases for the compiler to handle but in all cases I
used guard so far the block was never really needed. But I think this
is out of the scope of this thread.

L

On 31 May 2016 at 15:59, Adrian Zubarev via swift-evolution
 wrote:
> +1. This is example *is not* a single expression code block. There are 3
> expressions (the condition, the return value in the else block, and the
> primary return value).
>
> The `else` block is a returning single expression block. I can’t show the
> `guard` example without any returning scope.
>
> You said it yourself "everywhere in the language“. It’s not “everywhere“ if
> we would left out `guards` else-returning block.
>
> If we’d allow this we could also write:
>
> func test(boolean: Bool) {
> guard boolean else {}
> print("true")
> }
>
> This is useless and less readable.
>
> But we already can do this with closures:
>
> let nop = {} // useless
>
> switch value {
>...
>default: {}() // do nothing
> }
>
> --
> Adrian Zubarev
> Sent with Airmail
>
>
> ___
> 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 `return` optional in computed properties for a single case

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 2:36 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
>> Exactly.  You are allowed to omit `return` if the entire body only consists 
>> of `return some().expression`
> 
> Thats where the useless example comes in (but we don’t need this behavior at 
> all):
> 
> func foo(boolean: Bool) {
> 
> guard boolean else {}
> 
> print("true“)
> 
> }
> 
> I made some changes to the proposal: 
> https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md
>  
> 
> 
> Please review it again. :)

That looks good.  You might want to include more complex expressions just to 
make it clear that this isn’t limited to literal-returning expressions.  
Otherwise I think it covers it.  Thanks for putting this together!  I’ve wanted 
this for a long time… :)

> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> ___
> 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] Working with enums by name

[Leonardo Pessoa via swift-evolution]

Since we're talking a lot enums these days, I'd like to bring into
discussion a proposal that has been briefly mentioned in another
thread to enable working with enums using their names.

This is currently possible in the language but it's a bit burdensome.
You can just interpolate the value of the enum into a string to get
its name/representation as a string but you have to write case by case
the init methods for each enum to convert the string back to its
value. For example:

|   enum Planet : Int {
|  case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune
|
|  init?(caseName name : String) {
|  switch name {
|  case "Mercury":
|  self = .Mercury
|  case "Venus":
|  self = .Venus
|  case "Earth":
|  self = .Earth
|  case "Mars":
|  self = .Mars
|  case "Jupiter":
|  self = .Jupiter
|  case "Saturn":
|  self = .Saturn
|  case "Uranus":
|  self = .Uranus
|  case "Neptune":
|  self = .Neptune
|  default:
|  return nil
|  }
|  }
|   }
|
|   let planet = Planet(caseName: "Earth")!
|   print("\(planet) = \(planet.rawValue)") // Earth = 3

My proposal here is to let the compiler create these initialisers
automatically, just like with rawValue.

The reasoning here is simple: Enums in their basics are values, like
Int values or Double values, but limited to a closed set and
referenced in code by a name. Although they *may* have raw value
equivalents not all do (they don't need to). Using the name of the
enum value instead of any value associated with it also benefits
persistence since these associated values can change overtime while
the name is less likely to change.

As an example of the importance of this proposal, I mention the
company I work for who chooses to store (DB) the names of enum values
where they are used in persisted data arguing it's easier to debug and
support, and several web services we work with send enumerated values
as the strings of their names which we have to convert back to the
enum value when we receive. This proposal would simplify writing such
parts of the apps.

In case you're thinking, enums with associated values can also have
their instances created this way because there seems to be a default
representation for them in string interpolation. It's possible to be
done manually but would require a lot more of code and effort to be
converted back:

|   enum Platform {
|  case OSX(version: String)
|  case iOS(version : Int)
|   }
|
|   let plat = Platform.iOS(version: 9)
|   print("\(plat)") // iOS(9)
|
|   let plat2 = Platform.OSX(version: "10.10.4")
|   print("\(plat2)")  // OSX("10.10.4")

Furthermore, I'm aware the output of the string interpolation may be
altered by adopting certain protocols so it should also be interesting
for this proposal to add a property like .caseName to all enums to
ensure the correct string representation that would be converted back
to the enum value.

I'd like to hear your opinions before writing a proposal.
Thanks.

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

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Adrian Zubarev via swift-evolution]

Exactly.  You are allowed to omit `return` if the entire body only consists of 
`return some().expression`
Thats where the useless example comes in (but we don’t need this behavior at 
all):

func foo(boolean: Bool) {

    guard boolean else {}

    print("true“)

}

I made some changes to the proposal: 
https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md

Please review it again. :)
-- 
Adrian Zubarev
Sent with Airmail

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Christopher Kornher via swift-evolution]

> On May 31, 2016, at 1:00 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On May 31, 2016, at 12:52 PM, Xiaodi Wu  wrote:
>> These lines of reasoning are what have compelled me to conclude that `where` 
>> might not be salvageable.
> 
> To which, I'd add: `where` suggests there's a subordinate and semantic 
> relationship between the primary condition and the clause. There's no way as 
> far as I know this to enforce it in the grammar and the proposal allows both 
> clauses to be stated even without the connecting word.

OK. I am naive enough to try to informally define a rule that would make 
“where” required and cover all (?) cases in the proposal:

‘where’ is required after an if-let for any clause involving a variable or 
constant defined in that 'if let. All boolean expressions after the ‘where’ 
must reference at least one of constants defined by the ‘if let'

Allowed:

let a = a, b=b where b > 10 && a > 5 && b> a


Not allowed:
…
let a = a
let b = b where b > 10 && a > 5
b > a
...

…
let a = a
let b = b where b > 10
a > 5
b > a
…

This requires the use of commas because all inter-related ‘if let’ constants 
must be associated with a single ‘where'

This makes the use of ‘&&’ more natural, since everything to the right of 
“where” is a boolean expression

The formal grammar is left as an exercise :)

The downside:

I would not have to answer all the ‘Why won’t this compile?’ questions 
on stack overflow. Of course, I would not want to do that for the current 
syntax, either.


> You could make a vague argument, I suppose, for renaming `where` to `when` 
> but all in all, even killing `where` we benefit with better expressive 
> capabilities and a simpler grammar.
> 
> -- 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] [Pitch] Make `return` optional in computed properties for a single case

[L Mihalkovic via swift-evolution]

> On May 31, 2016, at 8:45 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I feel like return is very important part of guard statement. I understand 
> the requirement for consistency with properties/closures/functions, but I’ll 
> prefer to have some inconsistency in language in this case and require return 
> for guard. And in case I’ll have to choose all-or-nothig, I’ll give –1 for 
> the proposal. 
> What’s the problem with single-expression guards? guard cannot fall trough 
> and the type is inferred as the same as its parent closure has. 
> 
> If we’d like to have this consistence everywhere in the language, guards will 
> be part of that as well.
> 
> I’d interpret that as being able to write:
> 
> var x: Int8 { 20 }
> as opposed to:
> var x: Int8 { Int8(20) }
> Comment:
> 
> Integer literals are untyped and pick up the type of their context.
> 
> Joe Groff 
> 
so there is no way to draw a parallel between integer literals and say ‘value’ ?

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

Re: [swift-evolution] Variadic generics discussion

[L Mihalkovic via swift-evolution]

what I mean is I think it is perfectly doable as a runtime thing, without much 
apparent magic (the compiler support code is a different story), but it looks 
like a clean runtime story.

> On May 31, 2016, at 7:59 PM, Austin Zheng  wrote:
> 
> How so? I'm interested in anything that can get us away from having to 
> generating code at compile-time.
> 
> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic  > wrote:
> 
> What's interesting about the code in the manifesto is that it looks very much 
> like "..." is a runtime construct, as opposed to trying the get the compiler 
> to do the heavy lifting.
> 

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Brandon Knope via swift-evolution]

I could be pedantic and say that "previousInterestingFoo" now relies on the 
newly bound "foo" on assignment in the while loop keeping it relevant 
contextually. 

Ultimately, my responsibility as a user of the language is not to try to figure 
out the inner workings of the grammar or the compiler. It's not where my 
interests are or should be really.

My interests are the readability and expressiveness of using the language as I 
use the language. This is not a problem I have a solution for. But as a user of 
the language, dropping where and introducing semicolons in a lot of places will 
lead to much less readable code in my opinion, no matter what you say the 
compiler or grammar can or cannot do. 

This may seem harsh, but as a user and advocate for the users, it's hard for me 
to recommend a feature that makes the language less readable just to fix the 
grammar. Am I suppose to care about the compiler or the grammar? Or is the 
usability of the language more important to me?

At the end of the day it's not up to me or the other dissenters, but we can at 
least voice our (rather strong) opinions and that's okay. 

Compiler/grammar folks may strongly disagree with us but this is why we have 
community reviews: to bring together all users of all backgrounds to the 
discussion whether that be in compilers, grammar, teachers, etc. 

Will this push me to stop programming in Swift if approved? No. 

Will it make it a little less enjoyable for me to use? A little. 

Brandon 

> On May 31, 2016, at 2:52 PM, Xiaodi Wu  wrote:
> 
> See, I'd wondered about that early on. But it didn't sound like this was a 
> restriction that could be formalized straightforwardly in the grammar.
> 
> Even if it could, it is too restrictive. Consider:
> 
> ```
> var previousInterestingFoo = 0
> 
> while let foo = sequence.next() where previousInterestingFoo < 42 {
>   // determine if foo is interesting
>   // ...
>   if interesting {
> previousInterestingFoo = foo
>   }
> }
> ```
> 
> If we enforce a rule like you propose, then this example above, which 
> arguably does "make sense contextually," would no longer be acceptable.
> 
> Switching gears to a different argument: this proposal aims (among other 
> things) to provide a way to make arbitrary Boolean assertions after a let 
> binding in situations where the use of `where` is currently required but 
> reads absurdly. Whatever alternative grammar is proposed for these arbitrary 
> Boolean assertions will, by construction, *always* be useful regardless of 
> the variables used in the assertion.
> 
> Thus, if we keep `where` and enforce your proposed rule, you end up with two 
> ways to express the same thing; `where` clauses would permit a strict subset 
> of assertions that can be expressed using the alternative syntax. And, the 
> compiler is conscripted to be an opinionated arbiter of style. That's a huge 
> no-go.
> 
> Or, you might say, "I don't want to support arbitrary Boolean assertions 
> after let bindings at all!" Well then, if we try to enforce your proposed 
> rule, then a user who wants to write `let y = y where x < z` would be driven 
> to this gem of a workaround: `let y = y where (y == y && x < z)`.
> 
> These lines of reasoning are what have compelled me to conclude that `where` 
> might not be salvageable.
> 
>> On Tue, May 31, 2016 at 13:04 Brandon Knope  wrote:
>> Except some of us have proposed only allowing unwrapped or newly bound 
>> variables in the where clause:
>> 
>> if let y = y where y < z should work
>> 
>> If let y = y where x < z should be an error because it doesn't need to be in 
>> a where clause and doesn't make sense contextually. 
>> 
>> I understand the rationale about why it should be removed...but I find it a 
>> little extreme and a little "technical" to the point that some of the 
>> personality of the language will be lost...all for the sake being 
>> "technically" correct. 
>> 
>> This may be why some of us are against the proposal. 
>> 
>> Brandon 
>> 
>> 
>>> On May 31, 2016, at 1:16 PM, Xiaodi Wu  wrote:
>>> 
>>> The motivating example is a compelling illustration of a problem with the 
>>> current grammar. I don't think anyone would disagree that `if let y = y 
>>> where x < z` is an abomination.
>>> 
>>> Now, I see no principled criteria, and none have been proposed here, that 
>>> would be useful to restrict what can come after `where`. Moreover, I see no 
>>> contention with the argument that arbitrary Boolean assertions should be 
>>> possible after a let binding.
>>> 
>>> Finally, it is a stated goal of the core team that there shouldn't be 
>>> multiple 'dialects' of Swift, and that where possible there should be one 
>>> general solution rather than two options.
>>> 
>>> Given these premises, I have to conclude that *if* the motivating issue is 
>>> to be fixed, we must get rid of `where`.
>>> 
>>> 
 On Tue, May 31, 2016 at 11:53 Brandon Knope 

Re: [swift-evolution] Variadic generics discussion

[L Mihalkovic via swift-evolution]

well there is no macro system, and for the moment a clear statement from chris 
that this is not on the table in the short term. the code in the example looked 
like run-of-the-mill swift, except for the “…". so that leaves us with swift 
looking code that would be executed by the compiler, but with nothing 
particular to tell which parts to and which not. just a thought.


> On May 31, 2016, at 7:59 PM, Austin Zheng  wrote:
> 
> How so? I'm interested in anything that can get us away from having to 
> generating code at compile-time.
> 
> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic  > wrote:
> 
> What's interesting about the code in the manifesto is that it looks very much 
> like "..." is a runtime construct, as opposed to trying the get the compiler 
> to do the heavy lifting.
> 

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

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 2:13 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
>> Please remove the section on guard as any of the preceding will never have 
>> single expression top level code blocks if they contain a guard clause.
> 
> I didn’t get this at first but now I see your point, it’s because the whole 
> returning scope will need `return` at the very end so `guard` should follow 
> that rule.
> 
> 

Exactly.  You are allowed to omit `return` if the entire body only consists of 
`return some().expression`

> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 31. Mai 2016 um 21:00:43, Matthew Johnson (matt...@anandabits.com 
> ) schrieb:
> 
>> 
> ___
> 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 `return` optional in computed properties for a single case

[Adrian Zubarev via swift-evolution]

Please remove the section on guard as any of the preceding will never have 
single expression top level code blocks if they contain a guard clause.
I didn’t get this at first but now I see your point, it’s because the whole 
returning scope will need `return` at the very end so `guard` should follow 
that rule.


-- 
Adrian Zubarev
Sent with Airmail

Am 31. Mai 2016 um 21:00:43, Matthew Johnson (matt...@anandabits.com) schrieb:


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

Re: [swift-evolution] Variadic generics discussion

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 1:11 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> AFAICT compile-time code generation suffers from the C++ templates problem - 
> my understanding is that if you don't have access to the definition of the 
> template you can't specialize. A Swift (regular, non-variadic) generic 
> function can be called with any conforming type without need for 
> specialization through dynamic dispatch, with specialization still existing 
> as an optimization. Having the same apply to variadic generics would be a 
> significant advantage.

I believe there has been some discussion of packaging SIL (or something like 
that) with modules for at least some generic constructs to allow specialization 
across module boundaries.

> 
> On Tue, May 31, 2016 at 11:08 AM, David Sweeris  > wrote:
> Out of curiosity, why?
> 
> - Dave Sweeris
> 
>> On May 31, 2016, at 12:59 PM, Austin Zheng via swift-evolution 
>> > wrote:
>> 
>> How so? I'm interested in anything that can get us away from having to 
>> generating code at compile-time.
>> 
>> On Tue, May 31, 2016 at 10:04 AM, L. Mihalkovic 
>> > wrote:
>> 
>> What's interesting about the code in the manifesto is that it looks very 
>> much like "..." is a runtime construct, as opposed to trying the get the 
>> compiler to do the heavy lifting.
>> 
>> ___
>> 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] Ad hoc enums / options

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 2:04 PM, Erica Sadun  wrote:
> 
>> 
>> On May 31, 2016, at 12:35 PM, Matthew Johnson > > wrote:
>> 
>> I think I'm -1 on this.  It makes things easier for the implementer of the 
>> function and harder for the caller.  
>> 
>> It's not clear whether the caller could store an argument to pass in a 
>> variable, but if they could they would need to list out all cases in the 
>> type of the variable (unless these anonymous enums have structural 
>> subtyping).  This is fragile.  Any time that list changes all variable 
>> declarations will have to be updated.
>> 
>> Functions are implemented once and usually called more many times.  It's 
>> better for callers if you just write it like this:
>> 
>> enum FitOrFill { case fit, fill }
>> func scaleAndCropImage(
>> image: UIImage,
>> toSize size: CGSize,
>> operation: FitOrFill = .fit
>> ) -> UIImage {
>> 
>> So unless these anonymous enums are structurally subtyped I think it's a bad 
>> idea.  And introducing structural subtyping here seems like a pretty large 
>> hammer for this use case.
> 
> 
> From the caller's point of view, the type must be inferable and exactly match 
> a token listed in the declaration (which would also appear in Quick Help):
> 
> let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill)
> 
> You would not be able to assign `.fill` to a variable and use that for the 
> operation value.

If you are not allowing callers to store their argument in a variable then I am 
100% opposed to this.  That would the first case in Swift where you *MUST* 
provide a literal argument when calling a function, and *CANNOT* provide a 
value you store in a variable (possibly something you receive as an argument 
from somewhere else).  Why would we want to restrict the flexibility of callers 
in that way?

> 
> -- E

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

Re: [swift-evolution] Ad hoc enums / options

[Erica Sadun via swift-evolution]

> On May 31, 2016, at 12:35 PM, Matthew Johnson  wrote:
> 
> I think I'm -1 on this.  It makes things easier for the implementer of the 
> function and harder for the caller.  
> 
> It's not clear whether the caller could store an argument to pass in a 
> variable, but if they could they would need to list out all cases in the type 
> of the variable (unless these anonymous enums have structural subtyping).  
> This is fragile.  Any time that list changes all variable declarations will 
> have to be updated.
> 
> Functions are implemented once and usually called more many times.  It's 
> better for callers if you just write it like this:
> 
> enum FitOrFill { case fit, fill }
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> operation: FitOrFill = .fit
> ) -> UIImage {
> 
> So unless these anonymous enums are structurally subtyped I think it's a bad 
> idea.  And introducing structural subtyping here seems like a pretty large 
> hammer for this use case.


>From the caller's point of view, the type must be inferable and exactly match 
>a token listed in the declaration (which would also appear in Quick Help):

let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill)

You would not be able to assign `.fill` to a variable and use that for the 
operation value.

-- E

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

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 1:59 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
>> +1. This is example *is not* a single expression code block. There are 3 
>> expressions (the condition, the return value in the else block, and the 
>> primary return value). 
> 
> The `else` block is a returning single expression block. I can’t show the 
> `guard` example without any returning scope.
> 
> You said it yourself "everywhere in the language“. It’s not “everywhere“ if 
> we would left out `guards` else-returning block.

I was speaking casually and meant “top level code blocks that return a value”.  
You are right that I wasn’t totally clear about that.  I replied to your 
initial post with the clarification I believe is necessary.

> If we’d allow this we could also write:
> 
> func test(boolean: Bool) {
> guard boolean else {}
> print("true")
> }
> 
> This is useless and less readable.
> 
> But we already can do this with closures:
> 
> let nop = {} // useless
> 
> switch value {
>...
>default: {}() // do nothing
> }
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> 
> ___
> 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-0099: Restructuring Condition Clauses

[Erica Sadun via swift-evolution]

> On May 31, 2016, at 12:52 PM, Xiaodi Wu  wrote:
> These lines of reasoning are what have compelled me to conclude that `where` 
> might not be salvageable.

To which, I'd add: `where` suggests there's a subordinate and semantic 
relationship between the primary condition and the clause. There's no way as 
far as I know this to enforce it in the grammar and the proposal allows both 
clauses to be stated even without the connecting word. You could make a vague 
argument, I suppose, for renaming `where` to `when` but all in all, even 
killing `where` we benefit with better expressive capabilities and a simpler 
grammar.

-- E

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

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 12:35 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Here is the draft proposal: 
> https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md
>  
> 
> Did I covered everything case? If you find some mistakes feel free to provide 
> feedback so I can fix the proposal before I submit a PR.
> 
> 

This is a good start.  

"Make return optional and infer return type for single-expressions everywhere 
in the language:”

Everywhere in the language is too strong.  We should be more precise.  I 
believe we are talking about top level code blocks that only contain a single 
expression for the following constructs in the grammar:

function-body
getter-setter-block
getter-clause 
variable-declaration
subscript-declaration

Please remove the section on guard as any of the preceding will never have 
single expression top level code blocks if they contain a guard clause.

-Matthew

> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> +1
>> 
>> L
>> 
>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution
>> > wrote:
>> >
>> >> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution 
>> >>  wrote:
>> >>
>> >> It isn’t a special case because all other single-statement closures in 
>> >> the language work that way. It’s actually inconsistent now.
>> >
>> > Computed properties aren’t closures so it’s not inconsistent in that 
>> > sense. But it is inconsistent in that closures are the *only* 
>> > value-returning code blocks that are able to use this sugar. It would be 
>> > nice to see this sugar consistently allowed everywhere in the language.
>> >
>> >>
>> >>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution 
>> >>>  wrote:
>> >>>
>> >>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution 
>> >>>  wrote:
>> >>>
>>  The idea is simple:
>> 
>>  • Can we make return keyword optional in cases like this?
>>  • Shouldn’t this behave like @autoclosure or @noescape?
>>  type A {
>>  var characters: [Character] = …
>>  var string: String { String(self.characters) }
>>  var count: Int { 42 }
>>  }
>> 
>>  Is this worth a proposal or Swifty enough, what do you think?
>> 
>>  Sure I could write return, but why do we allow this behavior for 
>>  @noescape functions like map!?
>> >>>
>> >>> While I am not necessarily against this idea, I do wonder if it’s worth 
>> >>> making what’s going on here less obvious simply for the sake of being 
>> >>> able to omit a six character keyword. As I understand it, one of the 
>> >>> reasons ++/-- were removed was due to the increased "burden to learn 
>> >>> Swift as a first programming language.” This is the sort of thing that 
>> >>> becomes another one of those special cases that has to be explained to 
>> >>> someone new to Swift.
>> >>>
>> >>> /brian
>> >>>
>> >>> ___
>> >>> 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 
>> 
> 
> 
> ___
> 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 `return` optional in computed properties for a single case

[Adrian Zubarev via swift-evolution]

+1. This is example *is not* a single expression code block. There are 3 
expressions (the condition, the return value in the else block, and the primary 
return value). 
The `else` block is a returning single expression block. I can’t show the 
`guard` example without any returning scope.

You said it yourself "everywhere in the language“. It’s not “everywhere“ if we 
would left out `guards` else-returning block.

If we’d allow this we could also write:

func test(boolean: Bool) {
guard boolean else {}
print("true")
}
This is useless and less readable.

But we already can do this with closures:

let nop = {} // useless

switch value {
   ...
   default: {}() // do nothing
}

-- 
Adrian Zubarev
Sent with Airmail

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Xiaodi Wu via swift-evolution]

See, I'd wondered about that early on. But it didn't sound like this was a
restriction that could be formalized straightforwardly in the grammar.

Even if it could, it is too restrictive. Consider:

```
var previousInterestingFoo = 0

while let foo = sequence.next() where previousInterestingFoo < 42 {
// determine if foo is interesting
// ...
if interesting {
previousInterestingFoo = foo
}
}
```

If we enforce a rule like you propose, then this example above, which
arguably does "make sense contextually," would no longer be acceptable.

Switching gears to a different argument: this proposal aims (among other
things) to provide a way to make arbitrary Boolean assertions after a let
binding in situations where the use of `where` is currently required but
reads absurdly. Whatever alternative grammar is proposed for these
arbitrary Boolean assertions will, by construction, *always* be useful
regardless of the variables used in the assertion.

Thus, if we keep `where` and enforce your proposed rule, you end up with
two ways to express the same thing; `where` clauses would permit a strict
subset of assertions that can be expressed using the alternative syntax.
And, the compiler is conscripted to be an opinionated arbiter of style.
That's a huge no-go.

Or, you might say, "I don't want to support arbitrary Boolean assertions
after let bindings at all!" Well then, if we try to enforce your proposed
rule, then a user who wants to write `let y = y where x < z` would be
driven to this gem of a workaround: `let y = y where (y == y && x < z)`.

These lines of reasoning are what have compelled me to conclude that
`where` might not be salvageable.

On Tue, May 31, 2016 at 13:04 Brandon Knope  wrote:

> Except some of us have proposed only allowing unwrapped or newly bound
> variables in the where clause:
>
> if let y = y where y < z should work
>
> If let y = y where x < z should be an error because it doesn't need to be
> in a where clause and doesn't make sense contextually.
>
> I understand the rationale about why it should be removed...but I find it
> a little extreme and a little "technical" to the point that some of the
> personality of the language will be lost...all for the sake being
> "technically" correct.
>
> This may be why some of us are against the proposal.
>
> Brandon
>
>
> On May 31, 2016, at 1:16 PM, Xiaodi Wu  wrote:
>
> The motivating example is a compelling illustration of a problem with the
> current grammar. I don't think anyone would disagree that `if let y = y
> where x < z` is an abomination.
>
> Now, I see no principled criteria, and none have been proposed here, that
> would be useful to restrict what can come after `where`. Moreover, I see no
> contention with the argument that arbitrary Boolean assertions should be
> possible after a let binding.
>
> Finally, it is a stated goal of the core team that there shouldn't be
> multiple 'dialects' of Swift, and that where possible there should be one
> general solution rather than two options.
>
> Given these premises, I have to conclude that *if* the motivating issue is
> to be fixed, we must get rid of `where`.
>
>
> On Tue, May 31, 2016 at 11:53 Brandon Knope  wrote:
>
>> To be frank, I just find the proposed syntax to be more ugly and less
>> expressive.
>>
>> I just don't find the proposal compelling enough to take away one of the
>> truly "Swifty" syntaxes that I have used and loved.
>>
>> If there are other ways to keep "where" while fixing the ambiguity I
>> would rather explore that than require semicolons everywhere.
>>
>> I have a feeling that more would object but just aren't perusing the
>> mailing lists. I think we will see much more activity come WWDC
>>
>> Brandon
>>
>> On May 31, 2016, at 12:25 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> In English (and, I'm guessing, many other languages), semicolons are used
>> as a second 'tier' of separators when commas become ambiguous. I'm puzzled
>> that a proposal to bring this longstanding convention to Swift is raising
>> so many objections, even going so far as to prompt alternatives such as
>> this that break clearly useful shorthands.
>>
>> On Tue, May 31, 2016 at 10:44 David Hart via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Yet another alternative: would it be possible to disallow commas as
>>> variable declaration separators and use them for condition clause
>>> separators again:
>>>
>>> let a = 4, b = 8 // becomes illegal and requires to separate them on two
>>> lines
>>>
>>> if a > 4, let c = foo(), let d = bar(), c != d { // now comma is not
>>> ambiguous anymore
>>> }
>>>
>>> David.
>>>
>>> On 28 May 2016, at 02:30, Erica Sadun via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon 
>>> wrote:
>>>
>>> guard
>>> x == 0 && a == b && c == d &&
>>> let y = optional, w = optional2, v = 

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Matthew Johnson via swift-evolution]

> On May 31, 2016, at 1:16 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> I really like the proposal in case of properties and functions, but I really 
> don't want to have
> guard boolean else { "false” }

+1.  This is example *is not* a single expression code block.  There are 3 
expressions (the condition, the return value in the else block, and the primary 
return value).

> 
> I feel like `return` is very important part of `guard` statement.
> I understand the requirement for consistency with 
> properties/closures/functions, but I'll prefer to have some inconsistency in 
> language in this case and require `return` for `guard`. And in case I'll have 
> to choose all-or-nothig, I'll give -1 for the proposal.
> 
> I.e. IMO current `return` in properties and functions is less evil than 
> absent of `return` in `guard`.
> 
> On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:
>> Here is the draft proposal:
>> https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md
>> 
>> Did I covered everything case? If you find some mistakes feel free to
>> provide feedback so I can fix the proposal before I submit a PR.
>> 
>> 
>> 
>> --
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution
>> (swift-evolution@swift.org ) schrieb:
>> 
>>> +1
>>> 
>>> L
>>> 
>>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution
>>>  wrote:
>>> >
>>> >> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution 
>>> >>  wrote:
>>> >>
>>> >> It isn’t a special case because all other single-statement closures in 
>>> >> the language work that way. It’s actually inconsistent now.
>>> >
>>> > Computed properties aren’t closures so it’s not inconsistent in that 
>>> > sense.  But it is inconsistent in that closures are the *only* 
>>> > value-returning code blocks that are able to use this sugar.  It would be 
>>> > nice to see this sugar consistently allowed everywhere in the language.
>>> >
>>> >>
>>> >>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution 
>>> >>>  wrote:
>>> >>>
>>> >>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution 
>>> >>>  wrote:
>>> >>>
>>>  The idea is simple:
>>> 
>>>  • Can we make return keyword optional in cases like this?
>>>  • Shouldn’t this behave like @autoclosure or @noescape?
>>>  type A {
>>>    var characters: [Character] = …
>>>    var string: String { String(self.characters) }
>>>    var count: Int { 42 }
>>>  }
>>> 
>>>  Is this worth a proposal or Swifty enough, what do you think?
>>> 
>>>  Sure I could write return, but why do we allow this behavior for 
>>>  @noescape functions like map!?
>>> >>>
>>> >>> While I am not necessarily against this idea, I do wonder if it’s worth 
>>> >>> making what’s going on here less obvious simply for the sake of being 
>>> >>> able to omit a six character keyword. As I understand it, one of the 
>>> >>> reasons ++/-- were removed was due to the increased "burden to learn 
>>> >>> Swift as a first programming language.” This is the sort of thing that 
>>> >>> becomes another one of those special cases that has to be explained to 
>>> >>> someone new to Swift.
>>> >>>
>>> >>> /brian
>>> >>>
>>> >>> ___
>>> >>> 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
>> 
>> 
>> 
>> ___
>> 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 `return` optional in computed properties for a single case

[Adrian Zubarev via swift-evolution]

I really like the proposal in case of properties and functions, but I 
really don't want to have 
guard boolean else { "false" } 

I feel like `return` is very important part of `guard` statement. 
I understand the requirement for consistency with 
properties/closures/functions, but I'll prefer to have some inconsistency 
in language in this case and require `return` for `guard`. And in case I'll 
have to choose all-or-nothig, I'll give -1 for the proposal. 

I.e. IMO current `return` in properties and functions is less evil than 
absent of `return` in `guard`.
I could note in alternative section that `guard` might be left out from this 
consistency.



-- 
Adrian Zubarev
Sent with Airmail

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

Re: [swift-evolution] Ad hoc enums / options

[Christopher Kornher via swift-evolution]

Here is a correction to the equivalent declaration. It would be a 
RawRepresentable String enum to be compatible with serialization mechanisms 
e.g. JSON. and other representations. Again, the name could be auto-generated 
to keep the syntax succinct.

…

would be equivalent to

class MyImage  {
enum  ScaleCropFitFill : String {
case  Fit
case  Fill
} 
...


> On May 31, 2016, at 12:25 PM, Christopher Kornher  wrote:
> 
> Apologies for using you as a relay...
> 
>> Begin forwarded message:
>> 
>> From: Charlie Monroe via swift-evolution > >
>> Subject: Re: [swift-evolution] Ad hoc enums / options
>> Date: May 31, 2016 at 11:43:43 AM MDT
>> To: Charles Constant >
>> Cc: Swift Evolution > >, Christopher Kornher > >
>> Reply-To: Charlie Monroe > >
>> 
>> I have mixed feelings about this since it may lead to redeclarations over 
>> and over of the same values instead of actually declaring an enum.
> 
> 
> I have two suggested “improvements”
> 
> 1) Make the enum String raw-representable. Name it somehow. This does not 
> affect Erica’s original syntax.
> 2) Force an explicit name.
> 
> #2  does add to the length of function declarations, so it is a tradeoff. 
> Perhaps the name could be optional, but...
> 
> #2 would improve debug representations of the value by providing a name that 
> can be found in source code
> 
> In a full-featured metadata system, it would probably be nice to have a type 
> for the enum to simply the handling of all enums. 
> 
> #2 is more future-proof. Systems get more complex over time and one use of a 
> type becomes many. 
> The enum type name (auto-generated or required, it makes no difference) would 
> be scoped to the function’s namespace e.g. (fixing the typo) :
> 
> class MyImage  {
>   func scaleAndCropImage(
>   image: UIImage,
>   toSize size: CGSize,
>   operation: ScaleCropFitFill{ .Fit | Fill} = .Fit
> 
>   ) -> UIImage {…}
> }
> 
> would be equivalent to:
> 
> class MyImage  {
>   enum  ScaleCropFitFill {
>   case  Fit
>   case  Fill
>   } 
> 
>   func scaleAndCropImage(
>   image: UIImage,
>   toSize size: CGSize,
>   operation: ScaleCropFitFill = .Fit
>   ) -> UIImage {…}
> }
> 
> There are two ways that an implementation could evolve from having one use of 
> the enum in a call to multiple uses;
> 
> 1) The function is refactored into more functions internal to the original 
> function’s namespace: module/class/struct/enum.
>   In this case, it would be appropriate to leave the enum declaration in 
> function declaration to indicate that this is the only public use of the enum.
> 2) More public functions are created that use the enum
>   In this case, it would be appropriate to declare the enum within the 
> same scope. Existing code would not be affected. Smart editors could provide 
> this refactoring.
> 
> - Chris K

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

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Adrian Zubarev via swift-evolution]

I feel like return is very important part of guard statement. I understand the 
requirement for consistency with properties/closures/functions, but I’ll prefer 
to have some inconsistency in language in this case and require return for 
guard. And in case I’ll have to choose all-or-nothig, I’ll give –1 for the 
proposal.
What’s the problem with single-expression guards? guard cannot fall trough and 
the type is inferred as the same as its parent closure has.

If we’d like to have this consistence everywhere in the language, guards will 
be part of that as well.

I’d interpret that as being able to write:

var x: Int8 { 20 }
as opposed to:
var x: Int8 { Int8(20) }
Comment:

Integer literals are untyped and pick up the type of their context.

Joe Groff
—

Under “Proposed solution” you say (emphasis mine):

“Make return optional and infer return type for single-expressions everywhere 
in the language:”

However the return type isn’t inferred for computed properties or functions, 
and I don’t see type inference being discussed in the proposal (other than 
mentioning that closures have it).
Is it worth discussing? I was using Brent’s words here, because my English 
isn’t that great:

This actually doesn’t have anything to do with @autoclosure or @noescape. Any 
one-expression closure can omit the return statement and have an inferred 
return type.
I could remove that from the proposal to sort out any confusion. It should be 
crystal clear that return should be optional for single-expressions.

-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Ad hoc enums / options

[Erica Sadun via swift-evolution]

>> I have two suggested “improvements”
>> 
>> 1) Make the enum String raw-representable. Name it somehow. This does not 
>> affect Erica’s original syntax.
>> 2) Force an explicit name.
>> 
>> class MyImage  {
>>  func scaleAndCropImage(
>>  image: UIImage,
>>  toSize size: CGSize,
>>  operation: ScaleCropFitFill{ .Fit | Fill} = .Fit
>> 
>>  ) -> UIImage {…}
>> }
>> 
>> would be equivalent to:
>> 
>> class MyImage  {
>>  enum  ScaleCropFitFill {
>>  case  Fit
>>  case  Fill
>>  } 
>> 
>>  func scaleAndCropImage(
>>  image: UIImage,
>>  toSize size: CGSize,
>>  operation: ScaleCropFitFill = .Fit
>>  ) -> UIImage {…}
>> }

This is not the direction I'm hoping to move in.

If an enumeration is to be used in more than one place, it should be a proper 
enumeration. Swift already offers dependent type support.  Single-point ad-hoc 
enumerations create better semantics for moving from if statements that test on 
Boolean values to switch statements that test on phrases, without creating 
dependencies on other types. As Tony A points out, 

> Having argument labels solves some of the problems that come along with 
> boolean arguments, but "fitImage" is a great example where the false case 
> ("not fit?") doesn't really convey enough information (or can convey 
> misleading information).


-- E

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Vladimir.S via swift-evolution]

> What I'm hearing is that at least some developers would like to retain
> where clauses in case conditions and optional binding conditions but still
> allow the more controllable logic introduced by differentiating condition
> types with semicolons or newlines. Is that a fair summary?

I believe so. Personally I'm +1 for leaving `where` as-is and "allow the 
more controllable logic" from the proposal.


> * Should `where` clauses be allowed where the contents of the where clause
> have no connection to the condition that precedes it?
> * Is there a technical way to to check for such conformance?
> * Should the `where` clause be left unconstrained, as it currently is in
> switch statements and for loops, etc, which is consistent with the rest of
> the language but contrary to the spirit of safety in Swift?
> * Should `where` clauses be re-evaluated throughout the language?

I suggest to not introduce any rules for `where` at least in this proposal. 
Probably we can discuss all related to `where` in separate proposal.



On 31.05.2016 20:57, Erica Sadun via swift-evolution wrote:



On May 31, 2016, at 11:16 AM, Xiaodi Wu > wrote:

The motivating example is a compelling illustration of a problem with the
current grammar. I don't think anyone would disagree that `if let y = y
where x < z` is an abomination.

Now, I see no principled criteria, and none have been proposed here, that
would be useful to restrict what can come after `where`. Moreover, I see
no contention with the argument that arbitrary Boolean assertions should
be possible after a let binding.

Finally, it is a stated goal of the core team that there shouldn't be
multiple 'dialects' of Swift, and that where possible there should be one
general solution rather than two options.

Given these premises, I have to conclude that *if* the motivating issue
is to be fixed, we must get rid of `where`.



This proposal does affect where clauses in:

  * case conditions (case pattern initializer where-clause?)
  * optional binding conditions (optional-binding-head
optional-binding-continuation-list? where-clause?)

This proposal does not affect where clauses in:

  * for-in statements (for case? pattern in expression where-clause?
code-block)
  * case item lists (case-item-list → pattern where-clause? | pattern
where-clause? , case-item-list)
  * catch clauses (catch pattern? where-clause? code-block)
  * generic parameter clause's requirement clause

What I'm hearing is that at least some developers would like to retain
where clauses in case conditions and optional binding conditions but still
allow the more controllable logic introduced by differentiating condition
types with semicolons or newlines. Is that a fair summary?

Here is the where clause grammar:

where_clause = where where_expression
where_expression = expression

I think technically, by adding the new separators, the `where` need not be
disallowed. That leaves the following questions:

* Should `where` clauses be allowed where the contents of the where clause
have no connection to the condition that precedes it?
* Is there a technical way to to check for such conformance?
* Should the `where` clause be left unconstrained, as it currently is in
switch statements and for loops, etc, which is consistent with the rest of
the language but contrary to the spirit of safety in Swift?
* Should `where` clauses be re-evaluated throughout the language?

-- 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] Ad hoc enums / options

[Matthew Johnson via swift-evolution]

I think I'm -1 on this.  It makes things easier for the implementer of the 
function and harder for the caller.  

It's not clear whether the caller could store an argument to pass in a 
variable, but if they could they would need to list out all cases in the type 
of the variable (unless these anonymous enums have structural subtyping).  This 
is fragile.  Any time that list changes all variable declarations will have to 
be updated.

Functions are implemented once and usually called more many times.  It's better 
for callers if you just write it like this:

enum FitOrFill { case fit, fill }
func scaleAndCropImage(
image: UIImage,
toSize size: CGSize,
operation: FitOrFill = .fit
) -> UIImage {

So unless these anonymous enums are structurally subtyped I think it's a bad 
idea.  And introducing structural subtyping here seems like a pretty large 
hammer for this use case.

Sent from my iPad

> On May 31, 2016, at 12:44 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Big +1. I had similar thoughts a while back when I was writing some C++ or 
> Java code that had boolean arguments, and I found myself hating how 
> non-documenting they were and I would contrive two-valued enums to make call 
> sites look better. Having a crisp clean syntax for this would be fantastic 
> and encourage people to write self-documenting APIs.
> 
> Having argument labels solves some of the problems that come along with 
> boolean arguments, but "fitImage" is a great example where the false case 
> ("not fit?") doesn't really convey enough information (or can convey 
> misleading information).
> 
> 
>> On Tue, May 31, 2016 at 9:17 AM Erica Sadun via swift-evolution 
>>  wrote:
>> Here's a function signature from some code from today:
>> 
>> func scaleAndCropImage(
>> image: UIImage,
>> toSize size: CGSize,
>> fitImage: Bool = true
>> ) -> UIImage {
>> 
>> 
>> And here's what I want the function signature to actually look like:
>> 
>> func scaleAndCropImage(
>> image: UIImage,
>> toSize size: CGSize,
>> operation: (.Fit | .Fill) = .Fit
>> ) -> UIImage {
>> 
>> 
>> where I don't have to establish a separate enumeration to include ad-hoc 
>> enumeration-like semantics for the call. A while back, Yong hee Lee 
>> introduced anonymous enumerations (and the possibility of anonymous option 
>> flags) but the discussion rather died.
>> 
>> I'm bringing it up again to see whether there is any general interest in 
>> pursuing this further as I think the second example is more readable, 
>> appropriate, and Swifty than the first, provides better semantics, and is 
>> more self documenting.
>> 
>> Thanks for your feedback,
>> 
>> -- Erica
>> 
>> ___
>> 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] Ad hoc enums / options

[Erica Sadun via swift-evolution]

> Begin forwarded message:
> 
> From: Christopher Kornher 
> Subject: Fwd: [swift-evolution] Ad hoc enums / options
> Date: May 31, 2016 at 12:25:33 PM MDT
> To: Erica Sadun 
> 
> Apologies for using you as a relay...
> 
>> Begin forwarded message:
>> 
>> From: Charlie Monroe via swift-evolution > >
>> Subject: Re: [swift-evolution] Ad hoc enums / options
>> Date: May 31, 2016 at 11:43:43 AM MDT
>> To: Charles Constant >
>> Cc: Swift Evolution > >, Christopher Kornher > >
>> Reply-To: Charlie Monroe > >
>> 
>> I have mixed feelings about this since it may lead to redeclarations over 
>> and over of the same values instead of actually declaring an enum.
> 
> 
> I have two suggested “improvements”
> 
> 1) Make the enum String raw-representable. Name it somehow. This does not 
> affect Erica’s original syntax.
> 2) Force an explicit name.
> 
> #2  does add to the length of function declarations, so it is a tradeoff. 
> Perhaps the name could be optional, but...
> 
> #2 would improve debug representations of the value by providing a name that 
> can be found in source code
> 
> In a full-featured metadata system, it would probably be nice to have a type 
> for the enum to simply the handling of all enums. 
> 
> #2 is more future-proof. Systems get more complex over time and one use of a 
> type becomes many. 
> The enum type name (auto-generated or required, it makes no difference) would 
> be scoped to the function’s namespace e.g. (fixing the typo) :
> 
> class MyImage  {
>   func scaleAndCropImage(
>   image: UIImage,
>   toSize size: CGSize,
>   operation: ScaleCropFitFill{ .Fit | Fill} = .Fit
> 
>   ) -> UIImage {…}
> }
> 
> would be equivalent to:
> 
> class MyImage  {
>   enum  ScaleCropFitFill {
>   case  Fit
>   case  Fill
>   } 
> 
>   func scaleAndCropImage(
>   image: UIImage,
>   toSize size: CGSize,
>   operation: ScaleCropFitFill = .Fit
>   ) -> UIImage {…}
> }
> 
> There are two ways that an implementation could evolve from having one use of 
> the enum in a call to multiple uses;
> 
> 1) The function is refactored into more functions internal to the original 
> function’s namespace: module/class/struct/enum.
>   In this case, it would be appropriate to leave the enum declaration in 
> function declaration to indicate that this is the only public use of the enum.
> 2) More public functions are created that use the enum
>   In this case, it would be appropriate to declare the enum within the 
> same scope. Existing code would not be affected. Smart editors could provide 
> this refactoring.
> 
> - Chris K

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

Re: [swift-evolution] [Pitch] #warning

[Vladimir.S via swift-evolution]

Thank you Charlie, just exactly what I think regarding all these 
#errors/#warnings/comments etc


On 31.05.2016 19:53, Charlie Monroe via swift-evolution wrote:

The way I see it and would use it:

Directives:

*#error* - fatal error, the binary shouldn't compile - e.g. unknown OS host
and the code depends on underlying OS features.

*#warning* - it is a big deal, but allow the binary to compile for testing.
E.g. you know some feature isn't implemented yet and you want a warning so
that you don't forget to implement it before releasing it to the public. Or
as someone has mentioned (I have used #warning like this as well), have a
warning for internal builds so that you don't accidently upload an internal
build to AppStore (happened to me more than once).

Comments:

*TODO* - something that would enhance or improve the app, but the current
behavior is sufficient for release. E.g. "TODO - refactor this code", "TODO
- think of a better name for this function" - it's not fatal, crucial to
the app, but is "nice to have".

*FIXME* - place in code that is known to underperform or fail in certain
situations, but these situations are rather rare and aren't critical. E.g.
"FIXME - when there are 20 000 rows in this table view, it is slow", "FIXME
- when run from a read-only volume, this behaves weirdly".

One may argue that the comment-based markings can be handled by the IDE,
but IMO transferring language features onto IDE is wrong. These comments do
not appear anywhere within the log when the code is compiled.

Comments are IMO "silent/soft" warnings that are good to go through when
you have nothing else to do and look for a way to fix minor issues within
the app. But when you get those mixed with larger issues such as "missing
feature, do not release without it!", you can get a long list and not
notice the important ones on that list. Not to mention you need to
currently search for these manually each time.

Charlie



On May 30, 2016, at 10:57 PM, Christopher Kornher via swift-evolution
> wrote:



On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution
> wrote:



On May 29, 2016, at 10:36 PM, Charlie Monroe > wrote:


As to #warning, Swift’s use of warnings are significant different than
the use in C.  In C compilers, many of the warnings produced *should*
be errors, but can’t be because that effects language conformance and
could break a large body of code.


The example I've mentioned with #error, doesn't necessarily lead to an
error, but can just issue a #warning("Untested OS, proceed carefully.")
- it IMHO doesn't necessarily be fatal.


This doesn’t make sense to me.  If the code is untested, then it should
definitely be audited and check if it is enabled.  A #error is the
perfect approach for this case.


I have used warnings in other languages when “bringing-up” large code
bases. Using a #warning facility is helpful at these times. Counting the
messages provides a metric for unresolved questions. I don’t fully
understand Chris’s objection to a warning compiler directive, so I cannot
comment on that. A ‘Mark’ - like comment format would be almost as good.

There is a problem with ‘magic’ comment formats, though. Recently I have
had issues with mistyping “// MARK”. IIRC, “// mark” is not recognized.
Compiler directives do not have this problem. In Objective-C “#pragma
marl" is a compiler error. In swift, “// MARL” is silently treated as a
plain comment.



-Chris

___
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] [Pitch] Make `return` optional in computed properties for a single case

[Vladimir.S via swift-evolution]

I really like the proposal in case of properties and functions, but I 
really don't want to have

guard boolean else { "false" }

I feel like `return` is very important part of `guard` statement.
I understand the requirement for consistency with 
properties/closures/functions, but I'll prefer to have some inconsistency 
in language in this case and require `return` for `guard`. And in case I'll 
have to choose all-or-nothig, I'll give -1 for the proposal.


I.e. IMO current `return` in properties and functions is less evil than 
absent of `return` in `guard`.


On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:

Here is the draft proposal:
https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/-single-expression-optional-return.md

Did I covered everything case? If you find some mistakes feel free to
provide feedback so I can fix the proposal before I submit a PR.



--
Adrian Zubarev
Sent with Airmail

Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution
(swift-evolution@swift.org ) schrieb:


+1

L

On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution
 wrote:
>
>> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution 
 wrote:
>>
>> It isn’t a special case because all other single-statement closures in the 
language work that way. It’s actually inconsistent now.
>
> Computed properties aren’t closures so it’s not inconsistent in that sense.  
But it is inconsistent in that closures are the *only* value-returning code blocks 
that are able to use this sugar.  It would be nice to see this sugar consistently 
allowed everywhere in the language.
>
>>
>>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution 
 wrote:
>>>
>>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution 
 wrote:
>>>
 The idea is simple:

 • Can we make return keyword optional in cases like this?
 • Shouldn’t this behave like @autoclosure or @noescape?
 type A {
   var characters: [Character] = …
   var string: String { String(self.characters) }
   var count: Int { 42 }
 }

 Is this worth a proposal or Swifty enough, what do you think?

 Sure I could write return, but why do we allow this behavior for @noescape 
functions like map!?
>>>
>>> While I am not necessarily against this idea, I do wonder if it’s worth making 
what’s going on here less obvious simply for the sake of being able to omit a six character 
keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased 
"burden to learn Swift as a first programming language.” This is the sort of thing that 
becomes another one of those special cases that has to be explained to someone new to Swift.
>>>
>>> /brian
>>>
>>> ___
>>> 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




___
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