[swift-evolution] Recent change makes Swift 4 less safe.

The latest beta doesn’t allow you to append “()” to an enum name with no associated value in a switch case. This makes Swift less safe because appending that “()” is an excellent way to indicate that you are not ignoring the associated value in the swift case because there isn’t any. Suppose

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

code and don't comment will also continue > to do so. Do you have any evidence that making commenting harder would > improve code quality? > > On Mon, Jan 16, 2017 at 7:28 AM Amir Michail via swift-evolution > <swift-evolution@swift.org> wrote: > Why not replace al

[swift-evolution] [Proposal] Replace all Swift comments by end notes.

Why not replace all Swift comments by end notes at the end of each source file so as to minimize the impact of misleading/outdated comments on code comprehension? You don’t necessarily need to scroll to the end of the source file to read a referenced end note in the code since the IDE could

Re: [swift-evolution] Code comments that check code validity.

is written and working and intended to be enabled later on > should be activated by a feature-toggle (either a compile-time or a run-time > one) rather than commented out. > > On Sun, 15 Jan 2017 at 00:04 Amir Michail via swift-evolution > <swift-evolution@swift.org> wrote: > &

Re: [swift-evolution] Support for assertions/preconditions that sometimes fail.

ing. > Saagar Jha > >> On Jan 14, 2017, at 4:10 PM, Amir Michail via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> It’s quite common for an assertion/precondition that you thought should hold >> actually does not yet there is no bug. In t

[swift-evolution] Support for assertions/preconditions that sometimes fail.

It’s quite common for an assertion/precondition that you thought should hold actually does not yet there is no bug. In that case, you might want to remind yourself of this fact by commenting out the assertion/precondition (instead of deleting it) so that you don’t make the same mistake in the

Re: [swift-evolution] Code comments that check code validity.

> On Jan 14, 2017, at 6:56 PM, Xiaodi Wu wrote: > > > > On Sat, Jan 14, 2017 at 5:50 PM, Amir Michail > wrote: > >> On Jan 14, 2017, at 6:46 PM, Xiaodi Wu > > wrote: >> >>

Re: [swift-evolution] Code comments that check code validity.

w you to comment out fragments of a single statement, but > > the incremental value of devoting time to additionally support that is, it > > would seem, low. > > > > On Sat, Jan 14, 2017 at 17:18 Amir Michail via swift-evolution > > <swift-evolution@swift.org

Re: [swift-evolution] Code comments that check code validity.

w. > > On Sat, Jan 14, 2017 at 17:18 Amir Michail via swift-evolution > <swift-evolution@swift.org> wrote: > The code in a “code comment" must compile (not just be syntactically correct) > yet must not have any effect on the resulting executable. > > For

[swift-evolution] Code comments that check code validity.

The code in a “code comment" must compile (not just be syntactically correct) yet must not have any effect on the resulting executable. For example, commented entries in an array would be checked for compilability but would not be included in the executable. Such “code comments" would allow

[swift-evolution] Proposal: named invariants for variable declarations

Examples: invariant vectorIndex(v:Int) { return 0..<3 ~= v } var i:Int,vectorIndex: = 2 i = 3 // run-time error invariant positive(v:Int) { return v > 0 } invariant odd(v:Int) { return v % 2 == 1 } var x:Int, positive, odd = 5 x = 2 // run-time error func f(z:Int, positive, odd) { … } f(-3)

[swift-evolution] Proposal: Variable invariants

Examples: var x:(Int where 1…10 ~= x) = 5 var y:(Double where trunc(y*2) == y*2) = 3.5 x = 11 // run-time error y = 3.6 // run-time error typealias T = Double(y) where trunc(y*2) == y*2 var y2:T = 4.5 // type for 10x10 grid of integers typealias Grid = [[Int]](g) where g.indices == 0..<10 &&

[swift-evolution] Proposal: Support constant expressions in enum case raw values.

Example: enum A : [Int] { case B = [1,2,3] } Currently, the following error occurs: "raw value for enum case must be a literal" ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Why aren't source to source transformations part of the Swift language standard?

Source to source transformations are part of a developer’s job, don’t need a GUI, and can be done more easily and accurately by the Swift compiler. Moreover, the compiler could be made interactive taking in extra information from the developer as required during the "compile" (again without

Re: [swift-evolution] Why aren't source to source transformations part of the Swift language standard?

has the information required for source to source transformations and so it makes sense to embed these transformations in the compiler itself. > > Jacob > > On Tue, Dec 29, 2015 at 10:07 AM, Amir Michail via swift-evolution > <swift-evolution@swift.org <mailto:swift-ev

Re: [swift-evolution] Proposal: Support for commit comments

> On Dec 21, 2015, at 5:38 PM, Douglas Gregor <dgre...@apple.com> wrote: > > >> On Dec 21, 2015, at 11:07 AM, Amir Michail via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Upon a commit, these comments would be automatic

Re: [swift-evolution] Proposal: Support for commit comments

> On Dec 21, 2015, at 5:56 PM, Greg Parker <gpar...@apple.com> wrote: > >> >> On Dec 21, 2015, at 2:53 PM, Amir Michail via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Dec 21, 2

Re: [swift-evolution] Proposal: Support for commit comments

t Apple was all about integration to create seamless experiences? > >> On Dec 21, 2015, at 3:04 PM, Amir Michail via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Dec 21, 2015, at 6:03 PM, Brent Royal-Gordon <br...@architechies

[swift-evolution] Proposal: Make braces optional much like semicolons.

// braces are optional here but you could still put them in if you want to for i in 0..<10 for j in 0..<5 if i % 2 == 0 print(i+j) print(i*j) // braces are necessary because “print" is on the same line as ”if" for i in 0..<10 for j in 0..<5 if i % 2 ==

Re: [swift-evolution] Proposal: Make braces optional much like semicolons.

ibility of making braces OPTIONAL as shown in the examples. > Stephen > >> On Dec 20, 2015, at 10:17 AM, Amir Michail via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> // braces are optional here but you could still put them in if you want to &

Re: [swift-evolution] Proposal: Port open source productivity apps to Swift to gain insight into language evolution.

> On Dec 20, 2015, at 12:19 PM, Tino Heth via swift-evolution > wrote: > > >> My recommendation would be to port the open source TeXmacs to Swift. It’s by >> far the best coded and powerful productivity app that I have seen and should >> have replaced TeX/LaTeX

Re: [swift-evolution] Proposal: Rewrite Swift compiler in swift to get ideas for further language evolution.

om variables to scopes or types; and stacks to determine >> closures. Significantly, and unlike most programs in the real world, there >> is no interaction with users: the compiler knows all it needs about the >> outside world from the moment it is called. > > Personally,

Re: [swift-evolution] Proposal: Rewrite Swift compiler in swift to get ideas for further language evolution.

_the_damage_done>, > which has a number of rebuttals to what you’ve said below. > That’s an interesting article but it doesn’t address the issue of whether compiler code is more like normal programming than compiler standard library code. >> On Dec 19, 2015, at 4:41 PM, A