Re: [swift-evolution] Code blocks and trailing closures

I don't see any confusion with trailing closures vs if or guard. If you claim that a long block of 50 lines is hard to digest then that probably means it needs to be broken down in to smaller pieces. On Wed, Mar 15, 2017 at 8:27 AM Rien via swift-evolution < swift-evolution@swift.org> wrote: > >

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

Seems like it should work. Maybe it is a bug that should be reported to SR. Does this error occur for non-failable initializers? On Sat, Mar 11, 2017 at 12:33 AM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > Is this a feature or a bug? > > class Foo { > let bar: Int

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

I'd find it fantastic if they added var list: String... = 1, 2,3,4,5 However if they remove Variadic arguments then apple would need to remove it from their apis. To name a few... print NSPredicate(format:) UIAlertView Removing variadic arguments would be a breaking change though. They would

Re: [swift-evolution] Infer types of default function parameters

+1 I like that python style shorthand. On Sat, Mar 11, 2017 at 6:36 AM Daniel Leping via swift-evolution < swift-evolution@swift.org> wrote: > I'm always positive with shorthand declarations, though this is a good > example of ambiguity pron case. > > Signatures are signatures. Let's not mess

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

-1 Something like `42` will make things confusing. On Thu, Mar 9, 2017 at 5:53 PM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 9, 2017, at 04:40, Ross O'Brien via swift-evolution < > swift-evolution@swift.org> wrote: > > I could see a purpose for identifiers

Re: [swift-evolution] [Discussion] Static methods as global functions

-1 On Fri, Mar 10, 2017 at 6:18 AM Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > So the topic of global functions like min/max came up on the thread about > adding a standard clamp method, and it got me to thinking whether there was > a better way to define most global

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> Here, I can count on actions to be a non-empty array. It’s > self-documenting and type-safe. How would this work if arrays are > (implicitly or explicitly) convertible to variadic arguments? > > R+ > > On 26 Feb 2017, at 17:26, Derrick Ho via swift-evolution < > swift-evolutio

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

It makes sense since protocol do not allow final. It doesn't make much sense to allow the extensions to be exempt from this. Classes that inherit from it can still provide their own implementation of the supposed "final" protocol method which is contradictory to what final means. Protocol

Re: [swift-evolution] [Pitch] Introducing `Unwrappable` protocol

I disagree that the following is better guard unwrap foo else { ... } // simpler? It feels like you are re-using foo which previously was an optional but now is something else. If a variable is a cup, then you'd be reusing a cup that previously had a different drink in it. guard let foo = foo

Re: [swift-evolution] class indent in swift, history?

It might have to do with C history. Anything inside two curly braces usually had an increased indentation level. I always thought the switch statement was an oddball for not indenting the cases. On Tue, Mar 7, 2017 at 1:42 AM Will Stanton via swift-evolution < swift-evolution@swift.org> wrote: >

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

[owned self] is weird. [self] is probably better and is currently the way to explicitly capture a variable. On Sun, Mar 5, 2017 at 6:35 AM Daniel Leping via swift-evolution < swift-evolution@swift.org> wrote: > I think we can stretch it even further. Have an idea in mind. > > Automatically

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

2017 at 5:35 PM Zach Waldowski via swift-evolution < swift-evolution@swift.org> wrote: > I don't understand the question. It should turn it into a group of > NSStrings prefixed by a common name. That's how they're imported from > Objective-C, stripped of their common prefix. > >

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

Swift should be one-way. > > Sincerely, > Zachary Waldowski > z...@waldowski.me > > > On Sun, Feb 26, 2017, at 01:21 PM, Derrick Ho via swift-evolution wrote: > > I updated my proposal > <https://github.com/wh1pch81n/swift-evolution/blob/swift-enum-objc/pro

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

nce it is more explicit. foo(["a", "b", "c"] as String...) On Sun, Feb 26, 2017 at 7:59 PM Jose Cheyo Jimenez <ch...@masters3d.com> wrote: > On Feb 26, 2017, at 8:26 AM, Derrick Ho via swift-evolution < > swift-evolution@swift.org> wrote: > > In swi

Re: [swift-evolution] [Pitch] Allow trailing argument labels

-1 to this proposal. While it is true that adding the argument labels helps you "read" it better, you end up with an inverted binary operator. I'll call it a sandwich. Argument labels should be used to name an argument so the fact that there is no argument provided means that this is not a good

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

ss of the rawValue initializer. To use the “other > direction” analogy, you’d similarly want them to apply for rawValue-ed > structs alone. The reasons are the same: only the structs are > layout-compatible because enums are integers. > > Once you go down this route, perhaps it doesn’t make

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

That is an interesting solution. Haravikk's solution was a breaking change so it undoubtedly had resistance. If we were to merely allow Arrays to be cast as type String... then there were be nothing to break. String... is technically not a real type though, so when you use it anywhere outside

[swift-evolution] [pitch] Variadic Arguments should accept Arrays

In swift, a variadic argument can become an array without too much effort. func foo(_ va: String...) { let a: [String] = va } However, it seems odd to me that an array can not be converted into a variadic argument foo(["a", "b", "c"]) // <-error foo("a", "b", "c") // no error Other people

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

Does swift still use #? foo(#) It might be more obvious then foo(_) People might mistake it for foo(_:) if they are just glancing at it. But foo(#) looks special. On Thu, Feb 23, 2017 at 1:07 PM Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > FWIW, I do think the foo(_)

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

The back tick option is interesting. Back tick means "don't treat this as an expression" which allows us to use keywords in certain areas but have them. Act as something that isn't a keyword. let f = `foo()` However looking at it like this it almost looks like a string. On Thu, Feb 23, 2017 at

Re: [swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

Did you know you can use a static variable as a default parameter? class poncho { static var color= "yellow" func foo(color: String = poncho.color){} } I think instance members should not be allowed as default members though. It may lead to unexpected behavior. On Wed, Feb 22, 2017 at 11:06 PM

Re: [swift-evolution] Argument labels in callbacks

Argument labels on blocks arguments should be brought back. On Wed, Feb 22, 2017 at 4:26 AM Franklin Schrans via swift-evolution < swift-evolution@swift.org> wrote: > I don’t see why it should be available in function arguments. > > The separation of the type and its label makes sense

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

foo(_) seems better. A colon would imply there is an argument of which there is none. On Wed, Feb 22, 2017 at 4:52 AM Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote: > I'm personally in favor of foo(_), as the number of colons currently > lines up directly with the

Re: [swift-evolution] [Pitch] Allow trailing argument labels

I've read the pitch, but it isn't clear what the ask is or what benefit it would give. On Wed, Feb 22, 2017 at 8:05 AM Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > On 22 Feb 2017, at 11:48, Brent Royal-Gordon > wrote: > > On Feb 22, 2017, at 3:32

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

xample, maybe you want to introduce a feature > so that static members that are layout-compatible with String are bridged > as global strings with the supplied name. > > > > > On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution < > swift-evolution@swift.org> wrote: >

Re: [swift-evolution] [Pitch] Let's talk about submodules

Oh, I thought this would be another discussion about namespaces. On Mon, Feb 20, 2017 at 8:39 PM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 20, 2017, at 5:36 PM, Brent Royal-Gordon > wrote: > > > > Okay, lots of people want to

Re: [swift-evolution] 'Public' class visibility specifiers

I've thought about how to deal with override in a way that is consistent with the language. Maybe something like this? // publicly visible but can't be subclassed. public private(subclass) // publicly visible and may be subclasses within the module. The default public internal(subclass) //

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

ypedef NS_ENUM(NSInteger, IntEnum) { > IntEnumFoo = 1, > IntEnumBar = 2 > }; > > // Proposed (static or extern, depending on implementation) > NSString *const StrEnumFoo = @“foo"; > NSString *const StrEnumBar = @“baz"; > > In fact, I’d go a step further and say an

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

lobally initialized const in objc should be allowed the same treatment. > Though the only other type that comes to mind is float/double. > > On Feb 20, 2017, at 4:07 PM, Derrick Ho via swift-evolution < > swift-evolution@swift.org> wrote: > > Swift should not forsake objectiv

[swift-evolution] [pitch] Make swift enum string available to Objc

Swift should not forsake objective-c. At least not when it comes enum strings. Although swift enums are suppose to be swift only, I think we should add a new attribute to slightly relax that. I think a good attribute would be @objcstring. By adding @objcstring, an objective-c exclusive class

Re: [swift-evolution] A concern

The first time I read through the swift manual. I thought to myself, "swift is Apples version of C++" The book on c -- the C programming language by Brian kernighan -- is around 200 pages. As for objective c I've yet to see a book that covers more than a single chapter Before diving into cocoa

Re: [swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

What wrong with [unowned self] On Sat, Feb 18, 2017 at 11:01 PM Daniel Duan via swift-evolution < swift-evolution@swift.org> wrote: > This reminded me of an idea I had long time ago which will have a similar > effect: add a way to disable implicit captures for closures. FWIW. > > > On Feb 18,

Re: [swift-evolution] Pitch: Replacement for FileHandle

I agree that the current state of bug reporting through radars is unmotivating. We file these bug reports and have no idea if it even made a difference. After seeing this many times we just don't bother with bug reports. Sure I understand that internally apple uses duplicated issues to show how

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

There is no need to change it Since the context basically disambiguates the meaning of ! The next best thing is to compare it to false (val == false) // same as !val On Wed, Feb 15, 2017 at 3:02 PM David Waite via swift-evolution < swift-evolution@swift.org> wrote: > If someone came with a

Re: [swift-evolution] final + lazy + fileprivate modifiers

I think I we can live with the original three: public, internal, and private Where public is visible to all, Internal is visible to all within the module, and private is visible only to the class and the same file. We can still fulfill the same roles that the current five fill. Open can become

Re: [swift-evolution] final + lazy + fileprivate modifiers

I find the final keyword useful when I want to communicate that this class should not be subclassed. I think the behavior should remain the same since it is useful. On Sun, Feb 12, 2017 at 5:15 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > On Feb 12, 2017, at 3:52

Re: [swift-evolution] for in? optionalCollection {

let test: [Int]? = nil for b in test ?? [] where b != 42 { Print(b) } I don't think you need new syntax since what you want can be accomplished quite succinctly already On Sat, Feb 11, 2017 at 8:18 AM Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: for i in test ?? []

Re: [swift-evolution] Access level control on setter

Just for the sake of completeness... :) open open(set) var open_open = ""i open public(set) var open_public = "" open internal(set) var open_internal = "" open fileprivate(set) var open_fileprivate = "" open private(set) var open_private = "" public public(set) var public_public = "" public

Re: [swift-evolution] Is it possible to compile swift code to dynamic library ?

If you use the "swiftc" command it will create an executable. Maybe there is a command in there to create linker files which you can offer to your c project. Any one on this threat super knowledgeable on the "swiftc" command? On Thu, Feb 9, 2017 at 1:53 AM Zheng Ping via swift-evolution <

Re: [swift-evolution] Warning when omitting default case for imported enums

-1 I prefer to have enums enforce that all cases are met otherwise use a default value. If an API changes and adds new cases I want to know about it so that I can do something about it! If we hide it then weird and mysterious bugs might creep up On Tue, Feb 7, 2017 at 4:22 PM Tanner Nelson via

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

I have found it strange that operator characters are the only ones that may be used as operators. Sometimes Characters that look like operators are not. Why does there need to be a divide? Why can't an arbitrary set of characters become operator-ized? For example some people would like "and" to

Re: [swift-evolution] for-else syntax

I don't like the idea of for-else since it doesn't really add much value. It hardly saves you any typing. -1 On Mon, Feb 6, 2017 at 6:26 PM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 6, 2017, at 11:06 AM, Jordan Rose via swift-evolution < >

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

If the \ operator is not defined in swift, does it treat it as something that can be operator overloaded? On Sun, Feb 5, 2017 at 10:29 AM Nicolas Fezans via swift-evolution < swift-evolution@swift.org> wrote: > Dear all, > > This is a rather simple proposal to add '\' (backslash character) as a

Re: [swift-evolution] Annotation of Warnings/Errors

I feel like warnings showing up as you type are an IDE's responsibility. Annotations to delay warnings seem like noise. Once you get used to programming you don't need the annotations. If warnings are bothersome, then turn it off in the Xcode settings! On Thu, Feb 2, 2017 at 1:34 PM Pierre

Re: [swift-evolution] Proposal seed: gathering data to fix the NSUInteger inconsistency

Shouldn't NSUInteger always become UInt in swift? On Thu, Feb 2, 2017 at 12:07 AM Freak Show via swift-evolution < swift-evolution@swift.org> wrote: > I have a framework I wrote that maps Objective C objects to sqlite records > - deriving sqlite schema definitions from property definitions. You

Re: [swift-evolution] for-else syntax

Maybe we can add a new parameter "otherwise" to the forEach method [1,2,3,4].forEach({ // do something } , otherwise: { // do something if it is an empty array }) On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > I'm of two minds on this feature; I

Re: [swift-evolution] [Discussion] mailing list alternative

ion@swift.org> wrote: > +1 for either e-mail or GitHub issues. No need for yet another tool... > > R+ > > On 28 Jan 2017, at 01:21, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > > > On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolut

Re: [swift-evolution] The lack of namespaces is leading people astray

If you make a dynamic framework called APIFramework And add a public class called URL_ME You can instantiate it with APIFramework.URL_ME() from your project. I haven't tried to see if this would work with global variables but I assume it would. On Mon, Jan 30, 2017 at 3:09 PM Robert Widmann via

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

Boris, My Intent is to make it easier to develop dependency B. I may want to develop on a feature branch for dependency B so I'd like to use PM to force that to happen. I don't want to have to cd into the A folder and then cd into B to make that change. I want to control the whole thing from the

Re: [swift-evolution] [Discussion] mailing list alternative

I'm surprised there is so little support for JIRA. Anyone think it's a bad tool for the job? On Thu, Jan 26, 2017 at 6:38 PM Nevin Brackett-Rozinsky via swift-evolution wrote: > On Thu, Jan 26, 2017 at 1:54 PM, Austin Zheng via swift-evolution < >

Re: [swift-evolution] [Discussion] mailing list alternative

I don't like mailing lists since it is very easy to forget about a topic. What I noticed about mailing lists is that the most controversial topics live the longest. I think swift-evolution should be able discussing the stuff that matters for the future of swift. I think the best choice for that

Re: [swift-evolution] Optional Assignment Operator

-1 On Wed, Jan 25, 2017 at 1:11 PM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch > wrote: > > > > Really? My observation from a quick test is that "a? = b" assigns b to a > if a already has a value,

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

It probably is a good idea. Perhaps the changes can be done in the Package.swift file but allow nesting of dependencies. Suppose your dependency is like this where P is your current project P --> A --> B Normally P we would describe its dependency on A while B would be abstracted away. In A,

Re: [swift-evolution] Fixing raw enum types

enum Something: RawRepresentable { } Generics? On Mon, Jan 16, 2017 at 1:51 PM Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: > This idea by Karl made me branch off a new thread. > > 2017-01-16 21:28 GMT+03:00 Karl Wagner : > > It would be helpful for

Re: [swift-evolution] Equatability for enums with associated values

I think it is better to create a syntax for getting the associated values and then comparing them. enum Option { case foo(String) case bar(Int) case zip } let op = Option.foo("hello") let bb = Option.foo("world") // proposed tuple-like syntax op.foo.0 // returns Optional("hello") // then we

Re: [swift-evolution] Update on the Swift Project Lead

Have fun working at Tesla Mr Chris Lattner! I look forward to seeing tesla car apps that can be written in swift. On Wed, Jan 11, 2017 at 1:22 PM Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > > On 11 Jan 2017, at 18:18, John Pratt via swift-evolution < >

Re: [swift-evolution] Consolidate Code for Each Case in Enum

Interesting proposal Tim. So instead of repeating the enum cases multiple times we repeat the functions multiple times? I feel like this merely flipping the complexity but not really getting rid of it. On Tue, Jan 10, 2017 at 8:08 PM Tim Shadel via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] Update on the Swift Project Lead

Thanks Chris! Thanks to yours work we got an improved objc and swift. On Wed, Jan 11, 2017 at 4:33 AM Georgios Moschovitis via swift-evolution < swift-evolution@swift.org> wrote: > Good news for Chris and Ted, I guess, congrats guys :) > > I am wondering, what’s the future of Playgrounds, now

Re: [swift-evolution] Cancelable named defer statements

Its probably better to use a Boolean variable close_file to "cancel" it, rather than change the entire language. func openFile(kind: String) -> UnsafeMutablePointer? { var file = fopen("MyFile.txt", "r") var close_file = true defer { if close_file { fclose(file) }} // <-- if

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

*if let *is fine the way it currently is. It may be strange to newcomers since it is unique, but once you get used to it, it is super useful. On Sun, Jan 8, 2017 at 7:58 AM Georgios Moschovitis via swift-evolution < swift-evolution@swift.org> wrote: > I quite really like the `if let` syntax,

Re: [swift-evolution] Consolidate Code for Each Case in Enum

Currently we can write a helper method to aid in getting the values inside the enum associated value. Below is a fully working implementation: ``` enum Package { case box(String, Int) case circular(String) var associated: Associated { return Associated(package: self) } struct Associated {

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

On Jan 7, 2017, at 23:37, Derrick Ho wrote: I think pattern matching is the most compelling reason to keep tuples. If they were gone, how would we replace the following? switch (a, b) { case (value1, value2): case (value3, value4): } I really have to ask. What do

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

I think pattern matching is the most compelling reason to keep tuples. If they were gone, how would we replace the following? switch (a, b) { case (value1, value2): case (value3, value4): } On Sun, Jan 8, 2017 at 2:31 AM Derrick Ho wrote: > Don't remove tuples. > They make

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

Don't remove tuples. They make it very convenient to pass multiple values around. Tuples use .0 instead of [0] which prevents any index out of bounds issues at compile time rather than at run time. Tuples should not adopt a dictionary style access because dictionaries imply nil for any key that

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

+1️⃣ for unsafecompilable On Fri, Jan 6, 2017 at 6:22 PM Benjamin Spratling via swift-evolution < swift-evolution@swift.org> wrote: > > > -Ben > > Sent from my iPhone. > > > On Jan 6, 2017, at 5:15 PM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I wouldn’t be

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

( > EnumName_EnumCase) seems inconsistent with the current import of strings > from Obj-C to Swift. Could we find a way to unify them? > > On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution < > swift-evolution@swift.org> wrote: > > I'm trying to revive an old thr

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

ms inconsistent with the current import of strings from Obj-C to Swift. Could we find a way to unify them? On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote: I'm trying to revive an old thread. I'd like to hear from the community. Can we

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

So could we add a @trailing or @nontrailing to the block argument to toggle on and off the feature? On Wed, Jan 4, 2017 at 8:35 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

port of strings > from Obj-C to Swift. Could we find a way to unify them? > > On 31 Dec 2016, at 4:15 am, Derrick Ho via swift-evolution < > swift-evolution@swift.org> wrote: > > I'm trying to revive an old thread. I'd like to hear from the community. > > Can

Re: [swift-evolution] Move placement of 'throws' statement

John McCall +1 I agree. The placement should remain the same. On Tue, Jan 3, 2017 at 8:29 AM John McCall via swift-evolution < swift-evolution@swift.org> wrote: > On Dec 29, 2016, at 12:33 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > on Wed Dec 28 2016, Chris

Re: [swift-evolution] Switch statement tuple labels

In your first example the switch statement is evaluating whether the given tuple of type (_:bool, _:bool) matches another tuple of type (_: bool, y: bool) The type signature doesn't match. I believe the change would not be additive like you say because it seems like it would require a change in

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

Anyone on the core team like to say anything? On Fri, Dec 30, 2016 at 9:15 AM Derrick Ho wrote: > I'm trying to revive an old thread. I'd like to hear from the community. > > Can we make a swift enum string interoperable with Objective-C? > > Currently NS_STRING_ENUM ports

Re: [swift-evolution] Replace named returns with `out` parameters?

-1 On Wed, Dec 28, 2016 at 9:37 AM Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > –1. I'm not sure there's a reason to draw a line from > removal-of-tuple-splat to removal-of-tuple-returns, other than the idea > that they both involve tuples. In a lot of languages,

Re: [swift-evolution] Move placement of 'throws' statement

Dec 27, 2016 at 1:17 PM Xiaodi Wu <xiaodi...@gmail.com> wrote: > On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution < > swift-evolution@swift.org> wrote: > > I suppose "throws" could be enhanced to produce a compiletime enum > > fu

Re: [swift-evolution] Move placement of 'throws' statement

I suppose "throws" could be enhanced to produce a compiletime enum func bar() throws { throw NSError() throw MyEnumError.firstError } Under the hood each expression passed to "throw" could make something like enum bar_abcdefj_throw { case genericError // all NSError go here case

Re: [swift-evolution] Move placement of 'throws' statement

Daniel Leping, I am unfamiliar with java. Do you have any resources that describe the nightmare in detail? On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <2...@gmx.de> wrote: > -1 for specifying errors for throws. Please don't. Proven by practice in > java it's a nightmare. > > In Java, this topic is

Re: [swift-evolution] Move placement of 'throws' statement

I like the idea of "throw" having information about what might be thrown. Maybe you have an enum of errors that may be thrown. How would the programmer know what might get thrown if they don't know the implementation details? While adding the throwing info in the comments is good, we might be

Re: [swift-evolution] Move placement of 'throws' statement

I like to imagine "throws -> returnType" like a special tuple let t = (e: NSError?, r: returnType) Where "try" is a special function that accepts a tuple argument; a success closure; and one or more error blocks func try( _ t: (e: NSError?, r: returnType) , do: ()->() , catch: ((Error)->())...

Re: [swift-evolution] [SwiftPM] Proposal: Add support for test-only dependencies

We need this. On Mon, Dec 26, 2016 at 11:57 AM thislooksfun via swift-evolution < swift-evolution@swift.org> wrote: > (I think this is the right place for this suggestion, but please let me > know if I'm mistaken) > > There is currently no supported way to have some dependencies only used > for

Re: [swift-evolution] Move placement of 'throws' statement

I personally do not see anything wrong with its current placement. It may be there because it was based on an existing cocoa pattern from objective-c - (NSString *)bazWithError:(NSError **)error { ... } Because objective c could only return one thing, using pointer-to-pointer was needed to

Re: [swift-evolution] Switch statement using blocks for conditions

Can you not write this? switch condition { case 1: do { // } case 2: do { // } } On Fri, Dec 23, 2016 at 8:35 AM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > Hi Marco, > > This idea has already been discussed on this list; however, > source-breaking changes require

Re: [swift-evolution] "with" operator a la O'Caml?

I believe variables under private(set) can still be accessed with KVC (At least when the class inherits from nsobject.) On Thu, Dec 22, 2016 at 9:19 AM Andy Chou via swift-evolution < swift-evolution@swift.org> wrote: > Point taken. I think Swift supports both styles reasonably well. Initially >

Re: [swift-evolution] "with" operator a la O'Caml?

Jeremy, The problem you present is not a mutability problem but rather a cache design problem. If your hash value truly is expensive then you only want to calculated it when you need to... struct Person: Hashable { var firstName: String {didSet { _hashValue = nil }} var lastName: String

Re: [swift-evolution] "with" operator a la O'Caml?

That is correct Andy. Let-constant can not be assigned a new value after it gets its initial value. It is unclear why you are against turning your properties into var's. Because you are using structs, all properties are copied by value. struct Person { var name: String } let andy =

Re: [swift-evolution] "with" operator a la O'Caml?

struct Person { Var name: String = "" func with(name n: String) -> Person { var a = self a.name = name return a } } let andy = Person().with(name: "Andy") let brandon = andy.with(name: "Brandon") On Mon, Dec 19, 2016 at 10:28 AM Andy Chou via swift-evolution < swift-evolution@swift.org> wrote:

Re: [swift-evolution] URL Literals

I suppose if compile time validation is desired I guess we can do something similar to @ibdesignables. Except instead of live rendering UIViews we would render the url Marking a URL like this @urlvalidation("a URL string") Would make it fire a compiletime URL request and give a warning if it was

Re: [swift-evolution] URL Literals

let url = URL(string: "https://example.com;)! let url = #url("https://example.com;) Are not that different in length. It really isn't saving you much. I suppose you can try overloading an operator to get something to the effect you want. On Fri, Dec 16, 2016 at 6:19 PM Micah Hainline via

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Use protocols {get} Can be used for let {get set} Can be used for var On Thu, Dec 15, 2016 at 1:16 AM Benjamin Spratling via swift-evolution < swift-evolution@swift.org> wrote: > Howdy, > Thanks, I’ll consider this as an alternative. > I don’t see that this solves the issues of

Re: [swift-evolution] Pitch: Expose enum properties backed by bridgeable types to Objective-C

You can currently access swift enums from objective c provided that it is marked @objc and inherits from Int. Objectivec can not however access a swift enum that inherits from a string. I've asked the community about how they feel about enabling this but there was little to no response. On Thu,

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

g which needs to be done. > > > > -Ben > > > > Sent from my iPhone. > > > > On Dec 13, 2016, at 1:35 AM, Jean-Daniel <mail...@xenonium.com> wrote: > > > >> An interesting reading about testing private members: > >> > >> https://

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

It bugs me as well that we can not test private components using XCTest. Objective-c never had this problem since privacy doesn't exist. I would like to see a version of XCTest that allows us to test every component. On Mon, Dec 12, 2016 at 12:02 AM Benjamin Spratling via swift-evolution <

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

You may want to add the specific error to your proposal. *error: member operator '•|' must have at least one argument of type 'NonEmptyArray'* *public static func •|(lhs: Element, rhs: [Element]) -> NonEmptyArray* On Sat, Dec 10, 2016 at 11:49 PM Derrick Ho wrote:

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

I placed he code you wrote in the proposal in playgrounds and it works perfectly. (reproduced below). Overloading operators used to only happen globally and since swift 3 they allowed you to put then inside the class/struct public struct NonEmptyArray { fileprivate var elements: Array

Re: [swift-evolution] Any consideration for directoryprivate as a compliment to fileprivate?

-1 we don't need any more access modifiers. We already have an excessive amount: 5 On Thu, Dec 8, 2016 at 12:55 PM Jim Malak via swift-evolution < swift-evolution@swift.org> wrote: > Hi Tino, > This is my first use of this forum. I certainly did not mean to cause pain > for anyone. > At Gonzalo's

Re: [swift-evolution] What about renaming Optional.map to Optional.mapMe ?

If you are confused by what $0 represents then your shouldn't use the short hand version of writing a block. The long version includes the type which will remove all mysteries // What is $0 array.map { $0.method() } // No mystery of $0. It is clearly a String? array.map { (name: String?) ->

Re: [swift-evolution] What about renaming Optional.map to Optional.mapMe ?

Jay, I fail to see the point you are trying to make. Can you clarify why we need a new map method for an optional array of elements? On Tue, Dec 6, 2016 at 9:46 PM Jay Zhao via swift-evolution < swift-evolution@swift.org> wrote: It applies in theory to think Optional as a collect of one and for

Re: [swift-evolution] Passing class protocols to functions accepting AnyObject

Does the following expression evaluate to true? p is AnyObject If it does then you may have found a bug. On Sun, Dec 4, 2016 at 9:46 PM Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > The following currently does not work: > > protocol P: class {} > class C: P {} > >

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

True, adding the type would be redundant. Here is my revised solution. Which basically still allows you do use a different name besides newValue/oldValue set { let temperature = newValue // do stuff } didSet { let temperature = oldValue // do stuff } On Sun, Dec 4, 2016 at 12:47 AM Saagar Jha

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

I believe Erica's point about RIGHT NAMES ONLY is the most clear. While a block-like syntax using $0 is nice, it fails to communicate whether it is a newvalue or an oldvalue. Therefore instead of following a block-like pattern it should follow a delegate-function like pattern. This would remove

Re: [swift-evolution] A proposal for inline assembly

I feel like inline assembly is a very niche idea. Inline assembly is supported by c and by extension objective-c. //file.h void aCFunction(); //file.m void aCFunction() { int a=10, b; asm ("movl %1, %%eax; movl %%eax, %0;" :"=r"(b) /* output */ :"r"(a) /* input */ :"%eax" /* clobbered register */

  1   2   >