Re: [swift-evolution] String update

[Eneko Alonso via swift-evolution]

Thank you for the reply. The part I didn’t understand is if if giving names to 
the captured groups would be mandatory. Hopefully not.

Assuming we the user does not need names, the groups could be captures on an 
unlabeled tuple.

Digits could always be inferred to be numeric (Int) and they should always be 
“exact” (to match "\d"):

let usPhoneNumber: Regex = (.digits(3) + "-“).oneOrZero + .digits(3) + “-“ + 
.digits(4)

Personally, I like the `.optional` better than `.oneOrZero`:

let usPhoneNumber = Regex.optional(.digits(3) + "-“) + .digits(3) + “-“ + 
.digits(4)

Would it be possible to support both condensed and extended syntax? 

let usPhoneNumber = / (\d{3} + "-“)? + (\d{3}) + “-“ + (\d{4}) /

Maybe only extended (verbose) syntax would support named groups?

Eneko


> On Jan 16, 2018, at 10:01 AM, George Leontiev <georgeleont...@gmail.com> 
> wrote:
> 
> @Eneko While it sure seems possible to specify the type, I think this would 
> go against the salient point "If something’s worth capturing, it’s worth 
> giving it a name.” Putting the name further away seems like a step backward.
> 
> 
> I could imagine a slightly more succinct syntax where things like 
> .numberFromDigits are replaced by protocol conformance of the bound type:
> ```
> extension Int: Regexable {
> func baseRegex() -> Regex<T, Int>
> }
> let usPhoneNumber = (/let area: Int/.exactDigits(3) + "-").oneOrZero +
> /let routing: Int/.exactDigits(3) + "-" +
> /let local: Int/.exactDigits(4)
> ```
> 
> In this model, the `//` syntax will only be used for initial binding and 
> swifty transformations will build the final regex.
> 
> 
>> On Jan 16, 2018, at 9:20 AM, Eneko Alonso via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Could it be possible to specify the regex type ahead avoiding having to 
>> specify the type of each captured group?
>> 
>> let usPhoneNumber: Regex<UnicodeScalar, (area: Int?, routing: Int, local: 
>> Int)> = /
>>   (\d{3}?) -
>>   (\d{3}) -
>>   (\d{4}) /
>> 
>> “Verbose” alternative:
>> 
>> let usPhoneNumber: Regex<UnicodeScalar, (area: Int?, routing: Int, local: 
>> Int)> = / 
>>   .optional(.numberFromDigits(.exactly(3)) + "-“) +
>>   .numberFromDigits(.exactly(3)) + "-"
>>   .numberFromDigits(.exactly(4)) /
>> print(type(of: usPhoneNumber)) // => Regex<UnicodeScalar, (area: Int?, 
>> routing: Int, local: Int)>
>> 
>> 
>> Thanks,
>> Eneko
>> 
>> 
>>> On Jan 16, 2018, at 8:52 AM, George Leontiev via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Thanks, Michael. This is very interesting!
>>> 
>>> I wonder if it is worth considering (for lack of a better word) *verbose* 
>>> regular expression for Swift.
>>> 
>>> For instance, your example:
>>> ```
>>> let usPhoneNumber = /
>>>   (let area: Int? <- \d{3}?) -
>>>   (let routing: Int <- \d{3}) -
>>>   (let local: Int <- \d{4}) /
>>> ```
>>> would become something like (strawman syntax):
>>> ```
>>> let usPhoneNumber = /let area: Int? <- .numberFromDigits(.exactly(3))/ + 
>>> "-" +
>>> /let routing: Int <- .numberFromDigits(.exactly(3))/ + 
>>> "-"
>>> /let local: Int <- .numberFromDigits(.exactly(4))/
>>> ```
>>> With this format, I also noticed that your code wouldn't match "555-", 
>>> only "-555-", so maybe it would end up being something like:
>>> ```
>>> let usPhoneNumber = .optional(/let area: Int <- 
>>> .numberFromDigits(.exactly(3))/ + "-") +
>>> /let routing: Int <- .numberFromDigits(.exactly(3))/ + 
>>> "-"
>>> /let local: Int <- .numberFromDigits(.exactly(4))/
>>> ```
>>> Notice that `area` is initially a non-optional `Int`, but becomes optional 
>>> when transformed by the `optional` directive.
>>> Other directives may be:
>>> ```
>>> let decimal = /let beforeDecimalPoint: Int <-- 
>>> .numberFromDigits(.oneOrMore)/ +
>>>   .optional("." + /let afterDecimalPoint: Int <-- 
>>> .numberFromDigits(.oneOrMore)/
>>> ```
>>> 
>>> In this world, the `/<--/` format will onl

Re: [swift-evolution] String update

[Eneko Alonso via swift-evolution]

Could it be possible to specify the regex type ahead avoiding having to specify 
the type of each captured group?

let usPhoneNumber: Regex 
= /
  (\d{3}?) -
  (\d{3}) -
  (\d{4}) /

“Verbose” alternative:

let usPhoneNumber: Regex 
= / 
  .optional(.numberFromDigits(.exactly(3)) + "-“) +
  .numberFromDigits(.exactly(3)) + "-"
  .numberFromDigits(.exactly(4)) /
print(type(of: usPhoneNumber)) // => Regex


Thanks,
Eneko


> On Jan 16, 2018, at 8:52 AM, George Leontiev via swift-evolution 
>  wrote:
> 
> Thanks, Michael. This is very interesting!
> 
> I wonder if it is worth considering (for lack of a better word) *verbose* 
> regular expression for Swift.
> 
> For instance, your example:
> ```
> let usPhoneNumber = /
>   (let area: Int? <- \d{3}?) -
>   (let routing: Int <- \d{3}) -
>   (let local: Int <- \d{4}) /
> ```
> would become something like (strawman syntax):
> ```
> let usPhoneNumber = /let area: Int? <- .numberFromDigits(.exactly(3))/ + "-" +
> /let routing: Int <- .numberFromDigits(.exactly(3))/ + "-"
> /let local: Int <- .numberFromDigits(.exactly(4))/
> ```
> With this format, I also noticed that your code wouldn't match "555-", 
> only "-555-", so maybe it would end up being something like:
> ```
> let usPhoneNumber = .optional(/let area: Int <- 
> .numberFromDigits(.exactly(3))/ + "-") +
> /let routing: Int <- .numberFromDigits(.exactly(3))/ + "-"
> /let local: Int <- .numberFromDigits(.exactly(4))/
> ```
> Notice that `area` is initially a non-optional `Int`, but becomes optional 
> when transformed by the `optional` directive.
> Other directives may be:
> ```
> let decimal = /let beforeDecimalPoint: Int <-- .numberFromDigits(.oneOrMore)/ 
> +
>   .optional("." + /let afterDecimalPoint: Int <-- 
> .numberFromDigits(.oneOrMore)/
> ```
> 
> In this world, the `/<--/` format will only be used for explicit binding, and 
> the rest will be inferred from generic `+` operators.
> 
> 
> I also think it would be helpful if `Regex` was generic over all sequence 
> types.
> Going back to the phone example, this would looks something like:
> ```
> let usPhoneNumber = .optional(/let area: Int <- 
> .numberFromDigits(.exactly(3))/ + "-") +
> /let routing: Int <- .numberFromDigits(.exactly(3))/ + "-"
> /let local: Int <- .numberFromDigits(.exactly(4))/
> print(type(of: usPhoneNumber)) // => Regex routing: Int, local: Int)>
> ```
> Note the addition of `UnicodeScalar` to the signature of `Regex`. Other 
> interesting signatures are `Regex` or 
> `Regex`. Building parsers becomes 
> fun!
> 
> - George
> 
>> On Jan 10, 2018, at 11:58 AM, Michael Ilseman via swift-evolution 
>> > wrote:
>> 
>> Hello, I just sent an email to swift-dev titled "State of String: ABI, 
>> Performance, Ergonomics, and You!” at 
>> https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20180108/006407.html 
>> ,
>>  whose gist can be found at 
>> https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f 
>> . I 
>> posted to swift-dev as much of the content is from an implementation 
>> perspective, but it also addresses many areas of potential evolution. Please 
>> refer to that email for details; here’s the recap from it:
>> 
>> ### Recap: Potential Additions for Swift 5
>> 
>> * Some form of unmanaged or unsafe Strings, and corresponding APIs
>> * Exposing performance flags, and some way to request a scan to populate them
>> * API gaps
>> * Character and UnicodeScalar properties, such as isNewline
>> * Generalizing, and optimizing, String interpolation
>> * Regex literals, Regex type, and generalized pattern match destructuring
>> * Substitution APIs, in conjunction with Regexes.
>> 
>> ___
>> 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] adding toggle to Bool

[Eneko Alonso via swift-evolution]

I am yet another one that tries to never use !

It feels like bad heritage from C, and it probably should be removed from Swift 
in the same way for(;;) and ++/-- where removed. 

! does not provide any unique functionality, as it is redundant to “== false”. 
Other than syntax sugar, it does not add any value to the language. 

I feel a mutating toggle(), invert() or flip() method on Bool provides much 
more value. The non-mutating counterpart however should probably not be 
included in the standard library, as it would also be redundant to “== false”. 

Eneko Alonso 

> On Jan 12, 2018, at 14:34, Anders Kierulf via swift-evolution 
>  wrote:
> 
> I also avoid using ! for negation when possible, and `toggle` or `invert` 
> will be helpful, but in many cases I think the negative case is better 
> expressed directly. For example, I find that using `nonEmpty` instead of 
> !isEmpty makes the code easier to read: 
> 
>  extension String {
>  var nonEmpty: Bool { return !self.isEmpty }
>  }
> 
>  if !string.isEmpty { … }
> 
>  if string.isEmpty.inverted() { … }
> 
>  if string.nonEmpty { … }
> 
> For the case of `contains`, maybe define `lacks`?
> 
>  if !items.contains(item) { ... }
> 
>  if items.contains(item).inverted() { ... }
> 
>  if items.lacks(item) { ... }
> 
> Anders Kierulf
> 
>> On Jan 12, 2018, at 12:54 PM, Alejandro Martinez via swift-evolution 
>>  wrote:
>> 
>> I wouldn't go as far as to ask to fade out ! but in all my code I end
>> up doing == false just for readability. That ! knows who to hide
>> himself too well :P
>> 
>> On Fri, Jan 12, 2018 at 10:13 AM, Adrian Zubarev via swift-evolution
>>  wrote:
>>> I’m not sure if this would be considered or not, but I would like if the
>>> negation operator `!` would fade out.
>>> 
>>> If this is ever going to a review then I’d suggest that we add a pair of
>>> functions, one mutating and the other non-mutating.
>>> 
>>> extension Bool {
>>> mutating func invert() {
>>>   self = !self
>>> }
>>> 
>>> func inverted() {
>>>   return !self
>>> }
>>> }
>>> 
>>> I’d rather use `inverted` instead of `!` because of the readability this
>>> function provides.
>>> 
>>> if !items.contains(item) { ... }
>>> 
>>> if items.contains(item).inverted() { ... }
>>> 
>>> ——
>>> 
>>> I personally have some other extensions like:
>>> 
>>> extension Bool {
>>> @discardableResult
>>> func whenTrue(execute closure: () throws -> T) rethrows -> T? {
>>>   if self { return try closure() }
>>>   return nil
>>> }
>>> 
>>> @discardableResult
>>> func whenFalse(execute closure: () throws -> T) rethrows -> T? {
>>>   if !self { return try closure() }
>>>   return nil
>>> }
>>> }
>>> 
>>> But this is more a personal preference.
>>> 
>>> ——
>>> 
>>> That said, if the community is fine with the `invert/inverted` pair then I’d
>>> say go for it ;)
>>> 
>>> Am 12. Januar 2018 um 09:14:22, Nate Cook via swift-evolution
>>> (swift-evolution@swift.org) schrieb:
>>> 
>>> 
>>> On Jan 12, 2018, at 12:15 AM, Chris Eidhof via swift-evolution
>>>  wrote:
>>> 
>>> Hey SE!
>>> 
>>> When we have a bunch of nested structs:
>>> 
>>>   struct Sample {
>>>   var bar: Bar
>>>   }
>>> 
>>>   struct Bar {
>>>   var show: Bool
>>>   }
>>> 
>>>   var foo = Sample(bar: Bar(show: false))
>>> 
>>> It can be repetitive to toggle a deeply nested boolean:
>>> 
>>>   foo.bar.show = !foo.bar.show // duplication
>>> 
>>> I sometimes add a `toggle` extension on `Bool`
>>> 
>>>   extension Bool {
>>>   mutating func toggle() {
>>>   self = !self
>>>   }
>>>   }
>>> 
>>> This allows you to write the same code without duplication, and makes the
>>> intent clearer:
>>> 
>>>   foo.bar.show.toggle()
>>> 
>>> 
>>> I like it!
>>> 
>>> In other languages, I don't think the `toggle` would make as much sense, but
>>> the mutable self makes this very useful.
>>> 
>>> After I posted it on Twitter, it turns out I'm not the only one:
>>> https://twitter.com/PublicExtension/status/730434956376346624
>>> 
>>> I would have gone straight to a proposal, but I think we can do some
>>> bikeshedding about the name of `toggle`?
>>> 
>>> 
>>> Another verb that could work is `invert`.
>>> 
>>> The `!` operator that does this is the negation operator, but I think
>>> `negate` could sound to some like "make this false" rather than toggling.
>>> 
>>> Nate
>>> ___
>>> 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
>>> 
>> 
>> 
>> 
>> -- 
>> Alejandro Martinez
>> http://alejandromp.com
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> 

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Eneko Alonso via swift-evolution]

Now that I think of it, this type would be great for storing results from a SQL 
query run on a database, for instance.

This is a valid SQL statement:

SELECT `firstname`, `lastname`, `firstname` FROM `employees`;

Note there is two copies of “firstname”. Don’t ask why. All that matters is 
that is valid SQL and that storing the results on a Dictionary wouldn’t be 
possible without manipulation.

Thus, using DictionaryLiteral (aka TableRow) would make much sense. Users could 
then convert to a Dictionary with the new unifyingKeys initializer, or 
“deserialize” into custom models that can be initialized with the TableRow 
(maybe via Decodable).

Given a proper name, this type could be really useful in many cases.

Thanks,
Eneko


> On Jan 9, 2018, at 9:28 AM, Eneko Alonso via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> How about renaming DictionaryLiteral to Row, TabularRow or TableRow?
> 
> I think most developers are familiar with the idea that a table row contains 
> multiple columns (in specific order), and each column has a name and a value 
> (key/value).
> 
> Some other name suggestions:
> - Record (kind of an old name for table rows)
> - SortedDictionary (sorted dictionaries are missing on the standard library, 
> and could give a chance to make this type more widely used)
> 
> 
> Thanks,
> Eneko 
> 
> 
> 
> 
>> On Jan 9, 2018, at 9:19 AM, Nate Cook via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> 
>>>> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>>> 
>>>> I'm not sure a valid use case by a third party makes it hold its weight 
>>>> for inclusion in the stdlib.
>>> 
>>> You're definitely right, and that's why I wrote with the most humble tone I 
>>> could.
>>> 
>>> Yet, the design of the stdlib *requires* some speculation about use cases, 
>>> and speculation is *helped* by the exposition of actual uses. I'm not sure 
>>> readers of the mailing list had any idea of the use cases of the current 
>>> DictionaryLiteral, and maybe I helped a little.
>>> 
>>>> Reproducing its feature set is extremely trivial, and would probably allow 
>>>> you to hint the implementation details better for your use case.
>>> 
>>> Please define "trivial”.
>>> 
>>> In case anybody would wonder, in the line below the `row` variable is of 
>>> type Row which happens to adopt ExpressibleByDictionaryLiteral. It is not 
>>> of type DictionaryLiteral. The use case here is the ability to express a 
>>> row with a dictionary literal that accepts duplicated keys and preserves 
>>> ordering:
>>> 
>>> XCTAssertEqual(row, ["a": 1, "a": 2])
>> 
>> That’s great! In this case you aren’t using the DictionaryLiteral type, but 
>> a “dictionary literal”, which no one is suggesting we remove. If I’m 
>> understanding what you wrote, this is another case where the terrible name 
>> is making it super hard to discuss what we’re talking about. “Dictionary 
>> literals” and the ExpressibleByDictionaryLiteral protocol are safe!
>> 
>>> I don't see how anything could better fit this use case than the current 
>>> DictionaryLiteral. This is not *my* use case, but the use case of anyone 
>>> that wants to model database rows beyond the traditional (and ill-advised) 
>>> dictionary.
>>> 
>>> Some other users may come with other use cases that may also help the 
>>> stdlib designers choose the best solution.
>>> 
>>> Gwendal
>>> 
>>>> 
>>>> Zach
>>>> z...@waldowski.me <mailto:z...@waldowski.me>
>>>> 
>>>> 
>>>> On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
>>>>> 
>>>>>> Le 9 janv. 2018 à 08:06, Gwendal Roué via swift-evolution 
>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>>>>> 
>>>>>> 
>>>>>>> Le 9 janv. 2018 à 06:40, Nevin Brackett-Rozinsky via swift-evolution 
>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>>>>>> 
&g

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Eneko Alonso via swift-evolution]

How about renaming DictionaryLiteral to Row, TabularRow or TableRow?

I think most developers are familiar with the idea that a table row contains 
multiple columns (in specific order), and each column has a name and a value 
(key/value).

Some other name suggestions:
- Record (kind of an old name for table rows)
- SortedDictionary (sorted dictionaries are missing on the standard library, 
and could give a chance to make this type more widely used)


Thanks,
Eneko 




> On Jan 9, 2018, at 9:19 AM, Nate Cook via swift-evolution 
>  wrote:
> 
>> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution 
>> > wrote:
>> 
>>> 
>>> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution 
>>> > a écrit :
>>> 
>>> I'm not sure a valid use case by a third party makes it hold its weight for 
>>> inclusion in the stdlib.
>> 
>> You're definitely right, and that's why I wrote with the most humble tone I 
>> could.
>> 
>> Yet, the design of the stdlib *requires* some speculation about use cases, 
>> and speculation is *helped* by the exposition of actual uses. I'm not sure 
>> readers of the mailing list had any idea of the use cases of the current 
>> DictionaryLiteral, and maybe I helped a little.
>> 
>>> Reproducing its feature set is extremely trivial, and would probably allow 
>>> you to hint the implementation details better for your use case.
>> 
>> Please define "trivial”.
>> 
>> In case anybody would wonder, in the line below the `row` variable is of 
>> type Row which happens to adopt ExpressibleByDictionaryLiteral. It is not of 
>> type DictionaryLiteral. The use case here is the ability to express a row 
>> with a dictionary literal that accepts duplicated keys and preserves 
>> ordering:
>> 
>>  XCTAssertEqual(row, ["a": 1, "a": 2])
> 
> That’s great! In this case you aren’t using the DictionaryLiteral type, but a 
> “dictionary literal”, which no one is suggesting we remove. If I’m 
> understanding what you wrote, this is another case where the terrible name is 
> making it super hard to discuss what we’re talking about. “Dictionary 
> literals” and the ExpressibleByDictionaryLiteral protocol are safe!
> 
>> I don't see how anything could better fit this use case than the current 
>> DictionaryLiteral. This is not *my* use case, but the use case of anyone 
>> that wants to model database rows beyond the traditional (and ill-advised) 
>> dictionary.
>> 
>> Some other users may come with other use cases that may also help the stdlib 
>> designers choose the best solution.
>> 
>> Gwendal
>> 
>>> 
>>> Zach
>>> z...@waldowski.me 
>>> 
>>> 
>>> On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
 
> Le 9 janv. 2018 à 08:06, Gwendal Roué via swift-evolution 
> > a écrit :
> 
> 
>> Le 9 janv. 2018 à 06:40, Nevin Brackett-Rozinsky via swift-evolution 
>> > a écrit :
>> 
>> The ulterior question of whether preserving “DictionaryLiteral” is 
>> worthwhile, is apparently out of scope. Personally, I have a hard time 
>> imagining a compelling use-case outside of the standard library, and I 
>> doubt it’s being used “in the wild” (I checked several projects in the 
>> source-compatibility suite and found zero occurrences).
> 
> DictionaryLiteral is worthwhile. The SQLite library GRDB uses 
> DictionaryLiteral in order to build database rows (which may have 
> duplicated column names, and whose column ordering is important). This is 
> mostly useful for tests:
> 
> let row = try Row.fetchOne(db, "SELECT 1 AS a, 2 AS a")!
> XCTAssertEqual(row, ["a": 1, "a": 2])
> 
> Gwendal
 
 Chris Lattner's wrote:
 
> why is maintaining duplicate keys a feature?
 
> Since it is immutable, why not sort the keys in the initializer, allowing 
> an efficient binary search to look up values?
 
 
 I really wish both duplicated keys and key ordering would be preserved, 
 since both are needed for the above sample code.
 
 Should those features be lost, the sky wouldn't fall, that's sure. But 
 we'd have to write something much less easy to wrote and read:
 
 XCTAssertEqual(row.map { $0 }, [("a", 1), ("a", 2)])
 
 Gwendal
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Eneko Alonso via swift-evolution]

In regards of A, doesn’t this code cover al cases?

@incomplete enum {
  case pancake
  case waffle
  case juice
}

When the @incomplete tag is present, the compiler enforces (with an error) that 
all switches handle a default case:

switch breakfast {
  case .pancake:
  case .waffle:
  case .juice:
  default:  // <— default case must be present to compile
break
}

This is also allowed:

switch breakfast {
  case .pancake:
// only like pancakes and nothing else!
  default:  // <— default case must be present to compile
break
}

I think it is safe for the compiler not to warn users when new cases are 
introduced (by the new OS, for instance), in similar way as users are not 
warned when new methods are added to a class, or new classes added to a 
framework. For instance, if a new case is added for UILabel text alignment, I 
don’t _really_ need to know unless I wanted my app to support that case. Users 
would be able to get that information from the documentation.

In regards of B (select one of the choices to be chosen as the normal choice if 
no choice is made by the user), sounds like an edge case and should be left for 
a separate proposal.


Thank you,
Eneko


> On Jan 2, 2018, at 10:11 AM, Jason Merchant via swift-evolution 
>  wrote:
> 
> I think this whole thing has been unnecessarily convoluted. As a result, the 
> majority of the replies are rabbit holes.
> 
> In my opinion, the true root of the concept in question is as follows:
> 
> A list of something is desired:
> 1 - Pancake
> 2 - Waffle
> 3 - Juice
> 
> Developer wishes to be able to:
> A) Add new things to the list of choices in the future as they come up with 
> new ideas
> B) Sometimes select one of the choices to be chosen as the normal choice if 
> no choice is made by the user
> 
> A and B are separate desires. In some circumstances a developer may want to 
> add a new choice and make it the normal choice when there was no normal 
> choice was clarified before.
> 
> 
> 
> Part 2:
> 
> After this simple desire is clear, there should be two discussions:
> A) In a text only coding language, what would we like the syntax to look 
> like? (Without regard to past-bias. What should it really be, forget what 
> mistaken design choices were made in Swift in the past)
> B) How do we approach making this happen behind the scenes?
> 
> Bonus: Given that some of us have changed our approach to programming 
> significantly beyond text based coding, and into more dynamic mediums of 
> programming in other niches, and even here and there in Xcode - I would 
> recommend considering how the IDE would show a modern version of this 
> concept. I feel too often that Swift design syntax has a lack of awareness 
> between the distinctions of what the IDE should do, as opposed to what the 
> syntax of the language should be, and what should be handled behind the 
> scenes by automated tooling.
> 
> _
> 
> My opinion, in answering the above questions is in preference to a simple 
> easy to read and write syntax, something like the following:
> 
> choices Breakfast {
> Pancake, Waffle, Juice
> }
> 
> If a "default" choice is desired, it is obvious to me that I would select the 
> choice from the IDE, and it would be visually indicated that it was the 
> default.
> 
> When changes occur, whether new choices are added, old ones are removed or 
> changed, or a default is added, changed, or removed - a behind the scenes 
> automated tool analyzes the changes and presents migration options through 
> the IDE.
> 
> _
> 
> Sincerely,
> Jason
> 
> 
> 
> ___
> 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] namespacing protocols to other types

[Eneko Alonso via swift-evolution]

Modules do more than that. For instance, if two imported modules provide a type 
with the same name, you can distinguish (name-spacing) them by using 
ModuleA.Thing vs ModuleB.Thing. 

In regards of Modules being intended to be shipped separately, that is 
incorrect. You might be thinking of packages. 

In Swift 4, a package can contain multiple binaries, including executables and 
libraries. These, can be composed of one or many modules. 

Swift Package Manager handles this really well, and allows to organize the code 
separating it by features or concerns. 

I understand Xcode does not have very good support for modules yet, other than 
importing frameworks. But it is my understanding this is something the new 
Xcode’s build system will solve, hopefully by Xcode 10. 

I’m not against nesting protocol definitions, I can see a few cases where it 
could be nice to have them. But in regards of namespacing, I think using nested 
types is the wrong direction. 

Thank you,
Eneko Alonso 

> On Dec 29, 2017, at 19:00, Kelvin Ma  wrote:
> 
> Modules in Swift are really designed for code that is intended to be shipped 
> separately. as Jon found out modules are pretty heavyweight and introduce a 
> lot of unwanted abstraction and complexity when all you want to do is write 
> things in a namespace. (Also if you forgot, importing a module in Swift dumps 
> all of its symbols into the global namespace so Module.Thing is really 
> meaningless.) sometimes this is a good thing because no one wants to be 
> writing Glibc.fopen over and over especially when you have to #if #endif it 
> out every time with Darwin.fopen if you want your library to run on OSX but 
> this feature also makes modules ineffective as a namespacing scheme. 
> 
> On Fri, Dec 29, 2017 at 8:35 PM, Eneko Alonso  wrote:
>>> …all i wanted to do was write Thing:Namespace.Protocol
>> 
>> Have you thought of using Swift modules for that? Maybe that would be a 
>> better approach than trying to name-space within a module?
>> 
>> Regards,
>> Eneko Alonso
>> 
>>> On Dec 29, 2017, at 16:51, Kelvin Ma via swift-evolution 
>>>  wrote:
>>> 
>>> …all i wanted to do was write Thing:Namespace.Protocol
>>> 
 On Thu, Dec 28, 2017 at 4:43 PM, Adrian Zubarev via swift-evolution 
  wrote:
 Well again I don’t think we should disallow capturing the outer generic 
 type parameter just because you cannot use the protocol inside the outer 
 type atm., you still can add a type-eraser. To be honest such usage of the 
 existential is not even a requirement for the outer type. On there other 
 hand we might want to set the default for the associated type like I 
 showed in my previous message. The nested protocol could serve a 
 completely different purpose. Furthermore I still think that Generic.P 
 and Generic.P should be distinct protocols just like nested generic and 
 non-generic types are within an outer generic type. Sure there could be 
 other problems with ambiguity if you think of something like 
 GenericViewController.Delegate, but the disambiguation when conforming 
 to such protocols requires a different solution and is a well known 
 limitation today.
 
 That said you won’t design such nested types anyways if you know the 
 existing language limitation. I’d say let’s keep it simple in theory and 
 just align the nesting behaviour.
 
 About existentials:
 
 For that scenario I can only speak for myself. I wouldn’t want to allow 
 directly the where clause existentials like this. It is far better and 
 more readable when we force the where clause on typealiases instead. We 
 could lift that restriction later if we’d like to, but not the other way 
 around. I think it’s okay if we start with a small restriction first and 
 see if it adopts well (this is MHO), because this way it shouldn’t harm 
 anybody.
 
 
 
 
 Am 28. Dezember 2017 um 21:51:29, Karl Wagner (razie...@gmail.com) schrieb:
 
> 
> 
>> On 28. Dec 2017, at 12:34, Adrian Zubarev 
>>  wrote:
>> 
>> I disagree with some of your points. Do begin with, I don’t think we 
>> should disallow capturing the generic type parameter, because I think 
>> there might be a good way to prevent parameterization of nested 
>> protocols.
>> 
>> To me this only feels like a natural consequence of nesting protocols 
>> anyways. To achieve this we have to provide an explicit associated type 
>> which will have a default type that refers to the captured outer generic 
>> type parameter. At this point we discover another issue that we cannot 
>> disambiguate generic type parameter like associated types yet and would 
>> be forced to name the associated type of the protocol differently.
>> 
>> 

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Eneko Alonso via swift-evolution]

Hello everyone, 

My name is Eneko Alonso, iOS developer, new here on the list.

Is there a good summary anywhere that condenses the pros and cons of this new 
feature that have been discussed so far?

It is not clear to me why non-exhaustive would be the default, requiring adding 
`@exhaustive` otherwise. Has anyone discussed doing it the other way around, 
this is, defaulting to exhaustive (no changes with prior Swift versions) and 
adding a `@nonExhaustive` tag instead as needed?

Apologies if this has been covered already.

Regards and thank you everyone for making Swift better!
Eneko


> On Dec 27, 2017, at 10:26 PM, Riley Testut via swift-evolution 
>  wrote:
> 
> Actually, from the other email thread about this same topic (thank god forums 
> are almost here), I see the proposed syntax “final switch” for what I 
> referred to as “switch!”, which I prefer.
> 
> On Dec 28, 2017, at 12:17 AM, Riley Testut via swift-evolution 
> > wrote:
> 
>> -1.
>> 
>> I agree this is a problem, but I think this is the wrong solution. I think 
>> the solution should be on the client side, not on the framework author’s 
>> side.
>> 
>> I would be fine if enums from imported modules are non-exhaustive, as long 
>> as I can choose to treat them as exhaustive if I want to. And in that case, 
>> if a new case is introduced, I think a fatal error is a reasonable result.
>> 
>> The proposed “switch!” command would do just this, and I think that is the 
>> better answer for this. Adding an @exhaustive attribute doesn’t actually 
>> prevent someone from adding a case anyway, which I think is a big (and not 
>> really solvable) issue 路‍♂️
>> 
>> I know much has been said about this, but it’s just my 2c.
>> 
>> On Dec 27, 2017, at 9:42 AM, Thorsten Seitz via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
 The proposal is available here:
 https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
  
 
 What is your evaluation of the proposal?
 
>>> 
>>> -1
>>> 
>>> I would much prefer the solution proposed by Andrew Bennett in another 
>>> thread which solves all problems very nicely including the testability of 
>>> future cases by giving them a placeholder name:
>>> 
>>> From Andrew’s mail:
 public enum HomeworkExcuse {
   case eatenByPet
   case thoughtItWasDueNextWeek
   fallback unknown // NEW
 }
 
 Then I believe you would be able to have an exhaustive switch like this:
 
 switch thing {
   case eatenByPet: break
   case thoughtItWasDueNextWeek: break
   case unknown: break
 }
 
 Which would still allow compile-time errors if new cases are introduced, 
 while providing a concise way to show something is not exhaustible.
 
 This would also support existing enums with "unknown" equivalent cases 
 would be able to explicitly label those fields as fallback without needing 
 to make large code changes.
 
 I see no reason why you shouldn't be able to use ".unknown", which should 
 still allow this to be testable.
>>> 
>>> i.e. Andrew’s idea is to introduce a placeholder case instead of marking 
>>> the enum as exhaustive/non-exhaustive. This gives the future cases a handle 
>>> to be switched on and to be tested against. Very elegant.
>>> 
 Is the problem being addressed significant enough to warrant a change to 
 Swift?
 
>>> Yes, but the proposed solution is not as good as it should be, neglecting 
>>> to provide compile-time errors if new cases are introduced.
 Does this proposal fit well with the feel and direction of Swift?
 
>>> No, due to its shortcomings.
 If you have used other languages or libraries with a similar feature, how 
 do you feel that this proposal compares to those?
 
>>> None, but see Andrew Bennett’s idea above.
 How much effort did you put into your review? A glance, a quick reading, 
 or an in-depth study?
 
>>> Followed most of the discussion and review threads.
>>> 
>>> -Thorsten
>>> ___
>>> 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