Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On 4 Oct 2017, at 14:12, Mike Kluev wrote: > > On 4 October 2017 at 13:41, Alex Blewitt > wrote: > > The difference between the & and && operators isn't to do with the implicit > conversions; it's to do with whether both

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On 4 Oct 2017, at 13:55, Mike Kluev wrote: > > On 4 October 2017 at 13:41, Alex Blewitt > wrote: >> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution >> >

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution > wrote: > > on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong > > wrote: > > > Because, ideally, I’d love to be able to do: > > > > infix operator and:

Re: [swift-evolution] What's the Pages/Numbers/Keynote file's UTI in Drop

This isn't an appropriate question for the swift-evolution list. You might like to ask it on one of the Apple developer forums at https://forums.developer.apple.com Alex > On 2 Oct 2017, at 08:23, Yun Zeng via swift-evolution > wrote: > > Hi everyone, > Recently

Re: [swift-evolution] Documentation and comments

It's not clear what you are proposing or how it would be achieved. If you would like to spend some time looking into this in more detail, please feel free and post back here with the results of your investigations. Alex > On 17 Sep 2017, at 00:12, Omar Charif via swift-evolution >

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On 31 Aug 2017, at 13:53, Jonathan Hull via swift-evolution > wrote: > > A few thoughts: > > 1) I would like to see Xcode gain a couple more literal types using the same > strategy it does for Image and Color literals > > 2) I would LOVE to see simple equation

Re: [swift-evolution] "layoutSubviews()" and "layoutIfNeeded()" camel casing mistake

> On 14 Aug 2017, at 17:12, Matthias Heymann via swift-evolution > wrote: > > Hi, > > I noticed that strictly speaking, the camel casing of methods like > “layoutSubviews()” and "layoutIfNeeded()" in the UIView class is wrong: The terminology comes from UIView,

Re: [swift-evolution] Change 'for in' expression to for [] { (item) in ... }

> On 28 Jul 2017, at 17:19, Kwanghoon Choi via swift-evolution > wrote: > > Hello > > I found someone easy mistake using for in loop statement. > > Ex) > var i = 0 > for i in 0..<10 { } > print(i) > > And this user expected print(i) is “10” The variable shadows

Re: [swift-evolution] Fast String Comparison From String Arrays

If you're doing something like that, you probably want to end up with some kind of bloom filter. Alex > On 28 Jul 2017, at 13:54, Omar Charif via swift-evolution > wrote: > > Hi, > > I wonder whether there is already a way in Swift to compare a string against > a

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

> On 13 Jul 2017, at 23:14, David Hart via swift-evolution > wrote: > >> >> On 14 Jul 2017, at 00:21, Jordan Rose > > wrote: >> >> [Proposal: >>

Re: [swift-evolution] [Announcement] Godbolt Compiler Explorer adds Swift support

If you're interested in just having a look at SIL output, then I put a very basic GUI wrapper around invocations of swiftc -emit-sil and friends: https://github.com/alblue/SILInspector It also supports piping them through the demangler and whether or not

Re: [swift-evolution] VisualFoundation Framework

> On 1 Jun 2017, at 09:57, Jonathan Hull wrote: > > I could be wrong, but my understanding is that Foundation is being open > sourced as well, and distributed with Swift across various platforms. It is already open source; the source code for the Swift/Linux port is here:

Re: [swift-evolution] VisualFoundation Framework

> On 1 Jun 2017, at 03:48, Jonathan Hull via swift-evolution > wrote: > > Hi Everyone, > > I am not sure whether Swift Evolution’s charter extends to the common > foundation framework which will be distributed with Swift (If not, then I > hope this request reaches

Re: [swift-evolution] Yet another fixed-size array spitball session

> On 30 May 2017, at 16:27, David Sweeris via swift-evolution > wrote: > > On May 30, 2017, at 03:25, Pavol Vaskovic > wrote: > >> On Tue, May 30, 2017 at 7:51 AM, David Sweeris >

Re: [swift-evolution] Disallowing unreachable code

> On 29 Mar 2017, at 14:10, Jonathan Hull wrote: > > I think the idea is that it also adds a warning so you can find it later. @available(*, deprecated, message: "Don't forget to implement this") func unimplemented(_ file:String = #file,_ line:Int = #line) -> T {

Re: [swift-evolution] Disallowing unreachable code

On 29 Mar 2017, at 11:38, Jonathan Hull via swift-evolution wrote: > > >> On Mar 27, 2017, at 11:27 AM, John McCall via swift-evolution >> > wrote: >> >> In fact, we should probably double-down on this

Re: [swift-evolution] Swift null safety questions

> On 23 Mar 2017, at 02:25, Elijah Johnson via swift-evolution > wrote: > > On March 22, 2017 at 8:41:25 PM, Joe Groff (jgr...@apple.com > ) wrote: >> >> > On Mar 22, 2017, at 4:07 PM, Elijah Johnson > >

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On 21 Feb 2017, at 07:00, Jaden Geller via swift-evolution > wrote: > > We avoid forcing users to organize code in such an opinionated manner just to > please the compiler. Perhaps some submodules deserve a separate file, but I > think that choice should not be

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

> On 17 Feb 2017, at 05:50, Xiaodi Wu via swift-evolution > wrote: > > As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised > proposal in draft form. > > It proposes a source-breaking change for rationalizing which characters are > permitted in

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

> On 17 Jan 2017, at 11:46, Jeremy Pereira > wrote: > >> >> On 17 Jan 2017, at 11:28, Alex Blewitt wrote: >> >> >>> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution >>> wrote: >>> >>> On 17

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

On 16 Jan 2017, at 15:28, Amir Michail via swift-evolution wrote: > > 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? A strong -1 from me. Moving

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

> On 17 Jan 2017, at 11:10, Jeremy Pereira via swift-evolution > wrote: > > >> On 17 Jan 2017, at 02:38, thislooksfun via swift-evolution >> wrote: >> >> I really hate to bring Java up, but I really do think it got at least one >>

Re: [swift-evolution] [Proposal] Rename fatalError() API

> On 6 Jan 2017, at 23:15, David Sweeris via swift-evolution > wrote: > > >> On Jan 6, 2017, at 2:58 PM, D. Felipe Torres via swift-evolution >> > wrote: >> >> Yeah, it was meant as a joke. >> I'm well

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

> On 20 Nov 2016, at 05:48, Anders Bertelrud via swift-evolution > wrote: > > * What is your evaluation of the proposal? A way of building against a specific set of dependencies, rather than a variable set (or master), is needed in Swift. The current build

Re: [swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

OpenVMS isn't in the supported list of Swift packages, so comparing it to that is pointless. https://github.com/apple/swift/blob/c3b7709a7c4789f1ad7249d357f69509fb8be731/lib/Basic/LangOptions.cpp#L26-L36 static const StringRef SupportedConditionalCompilationOSs[] = { "OSX", "tvOS",

Re: [swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

> On 11 Nov 2016, at 03:48, Drew Crawford wrote: > > grep -R "import Glibc" ~/Code --include "*.swift" | wc -l > 297 > > As someone who might be characterized as suffering from the problem this > proposal purports to solve, I am not convinced. > > The primary

[swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

Although out of scope for phase 1, something that keeps cropping up in a variety of Linux/Darwin Swift scripts is the conditional inclusion of Darwin or GlibC per platform. The last point was an observation that creating a 'nice' wrapper for LibC or a cleaned up POSIX API is a non-goal:

Re: [swift-evolution] [Meta] Let's talk TouchBar + Unicode

> On 29 Oct 2016, at 11:10, Haravikk via swift-evolution > wrote: > > Part of the problem for emoji is that the macOS special characters menu is so > awkward to use; coincidentally I actually posted an enhancement request to > the Apple bug reporter only yesterday

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

The "Symbol, Other" category contains "Sign of the Horns" 落 which was one of the problems with the identifier/operator that kicked off these discussions. http://www.fileformat.info/info/unicode/char/1f918/index.htm So it would break some existing cases, e.g.: 1> let \U+1F913 = "nerd face" 邏:

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

I support this in principle, having suggested similar things in the past. I would suggest, however, that to simplify the discussion and the proposal itself, that 'reserving operators at this time' and 'appease specific example that Chris Lattner proposed just so that it isn't outright denied'

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

> On 18 Oct 2016, at 20:46, Guoye Zhang via swift-evolution > wrote: > >> >> 在 2016年10月18日，15:30，David Waite > > 写道： >> >> >>> On Oct 18, 2016, at 12:17 PM, Guoye Zhang via swift-evolution >>>

Re: [swift-evolution] Pitch: disallow `()` from Switch statement case satisfaction

On 13 Oct 2016, at 11:06, Haravikk via swift-evolution wrote: > >> >> On 11 Oct 2016, at 19:43, Erica Sadun via swift-evolution >> > wrote: >> >> I thought this was long gone but today I found out it is

Re: [swift-evolution] private & fileprivate

> On 8 Oct 2016, at 20:01, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution > > wrote: > >> On 8 Oct 2016, at 16:47, Braeden Profile

Re: [swift-evolution] Unicode identifiers & operators

It would probably make sense to define the supported characters based on their category, rather than abstract ranges of character sets. For example, using the Letter and Number categories might be sufficient for defining identifiers.

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

Vapor's Core package expresses a target called simply 'libc': https://github.com/vapor/core/blob/master/Sources/libc/libc.swift As a result, their Swift files simply say "import libc"

Re: [swift-evolution] Deprecating Trailing Closures

> On 25 Mar 2016, at 08:10, Haravikk via swift-evolution > wrote: > > >> On 24 Mar 2016, at 21:08, Howard Lovatt wrote: >> >> I use trailing closures all the time because I find the brackets too noisy, >> like ; at the end of a line is