Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

I do like this to a point, but it ascribes special compiler behavior to specific argument labels which feels odd. If someone defined another operator function with a completely different argument label, would it just be ignored? If a developer makes a typo, that could be a subtle bug that may

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

I too have a little trouble with the suggested trampoline syntax: > static prefix func ++(value: inout Self) -> Self > static postfix func ++(value: inout Self) -> Self I agree with Brent that the most appropriate way to write the trampoline itself would be something more like: ``` static

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

Another +1 to Jacob's suggestion, and of course +1 to the intent of the proposal itself. On Tue, May 17, 2016 at 10:17 PM, Austin Zheng via swift-evolution < swift-evolution@swift.org> wrote: > I like Jacob's suggestion of "init(describing:)", and I also think the > review team should consider

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

I like Jacob's suggestion of "init(describing:)", and I also think the review team should consider the global function alternative. My main goal is also preventing silently incorrect code. Austin > On May 17, 2016, at 10:14 PM, Karl Wagner via swift-evolution >

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

I would still prefer a global function; because the output is from reflection, it’s really more for debugging purposes than actually serialising something. But any change to this gets a +1 from me. It’s too easy to accidentally call this instead of one of the other argument-less initialisers on

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0087: Rename lazy to @lazy

> On May 17, 2016, at 9:14 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md > > The proposal says this at the beginning: > >> Swift's rule for attribues/keywords

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

> Additionally, I am generally +1 for the same reasons as Brent, but I > have another caveat as well: > > Defining prefix and postfix functions looks like this in the proposal: > > static prefix func ++(value: inout Self) -> Self > static postfix func ++(value: inout Self) -> Self > > yet the

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

+1 -Thorsten > Am 16.05.2016 um 23:06 schrieb Joe Groff via swift-evolution > : > > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd > expect, but does lead to problems when an 'as' expression appears as part of > a comparison: > >

Re: [swift-evolution] Enhanced existential types proposal discussion

On Tue, May 17, 2016 at 1:25 PM, Matthew Johnson wrote: > > > >> >> >> Within the angle brackets are zero or more 'clauses'. Clauses are >> separated by semicolons. (This is so commas can be used in where >> constraints, below. Better ideas are welcome. Maybe it's not

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

> * What is your evaluation of the proposal? I think this is a good and long-needed change. I also think that the matching protocols should be renamed to correspond to the initializers used to invoke them: CustomStringConvertible should become PrintingStringConvertible, and

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

On 5/18/2016 12:03 AM, Brent Royal-Gordon via swift-evolution wrote: > I'm in favor, with one small concern: > >> Then, the protocol author is responsible for providing a generic global >> trampoline operator that is constrained by the protocol type and delegates >> to the static operator on

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

> UPDATED APPROACH > > Our updated approach focuses on the two most important conventions: one for > initialization and one for representation. > > 1. `Initializable` > > `Initializable` designates protocols that convert *from* a type or from an > associated type mentioned in the protocol

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

+1 (replying here because I can't find the root and I agree with this evaluation). ~Robert Widmann 2016/05/17 22:07、Trent Nadeau via swift-evolution のメッセージ: > * What is your evaluation of the proposal? > +1. A very simple API change that fixes a footgun in

Re: [swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

+1. A lot of (mostly functional) languages that need to disambiguate type constructors from terms enforce this as a requirement to great effect. ~Robert Widmann 2016/05/17 21:56、T.J. Usiyan via swift-evolution のメッセージ: > Could we reconsider rejecting the uppercase

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

+1 converting to a string is definitely lossy for most cases. On Wed, May 18, 2016 at 12:09 AM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > * What is your evaluation of the proposal? >> > > +1, because: > - I believe the default/generic "printing"

Re: [swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

+1 'default' alone makes this worth it. On Tue, Apr 26, 2016 at 5:28 PM, Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote: > +1 > I think it's a good thing. I don't think that it would introduce any bad > ambiguities for the human reader. E.g. "case .default:" may look

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0087: Rename lazy to @lazy

> > https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md The proposal says this at the beginning: > Swift's rule for attribues/keywords is that keywords usually modify type of > variable; attributes do not. [citation needed] As far as I can tell, this

Re: [swift-evolution] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

I've been thinking about the "conversion to some other type from this protocol" case for a while since it often seems to go against the guidance to add a property for this conversion. `Convertible` is always an awkward Protocol to write, in my opinion. Is there a chance that we simplify the the

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

> > * What is your evaluation of the proposal? > +1, because: - I believe the default/generic "printing" initializer is not commonly used (at least, not on purpose). - The new argument label clearly indicates what the initializer does. I would also submit for consideration

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

* What is your evaluation of the proposal? +1. A very simple API change that fixes a footgun in the standard library. * Is the problem being addressed significant enough to warrant a change to Swift? Yes. * Does this proposal fit well with the feel and direction of Swift?

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

> The review of "SE-0091: Improving operator requirements in protocols" begins > now and runs through May 23. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md > * What is your evaluation of

Re: [swift-evolution] [Review] SE-0087: Rename lazy to @lazy

* What is your evaluation of the proposal? +1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes. It's more consistent, both with the rules for keywords vs. attributes and with future improvements with property behaviors, as mentioned in the

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

* What is your evaluation of the proposal? +1. Although I would prefer something like: precedence(greaterThan: LogicalAnd) to: precedence(> LogicalAnd) I think the latter is more difficult to read, and I just find the idea of using an operator in an operator/precendencegroup definition

Re: [swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

Could we reconsider rejecting the uppercase and lowercase conventions as a syntactic requirement? While I still disagree with enum cases not being UpperCamelCase, that decision narrows the 'approved' enough that the syntactic requirement would line up with guidance. It would also make teaching the

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

* What is your evaluation of the proposal? +1 * Is the problem being addressed significant enough to warrant a change to Swift? Yes. Definitely. Operator overloading is currently fine in only the simplest of cases. * Does this proposal fit well with the feel and direction

[swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

Hello Swift community, The review of "SE-0091: Improving operator requirements in protocols" begins now and runs through May 23. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md Reviews are an

[swift-evolution] [Review] SE-0090: Remove .self and freely allow type references in expressions

Hello Swift community, The review of "SE-0090: Remove .self and freely allow type references in expressions" begins now and runs through May 23. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md Reviews are an

[swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

Hello Swift community, The review of "SE-0089: Renaming String.init(_: T)" begins now and runs through May 23. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md Reviews are an important part of the

[swift-evolution] [Review] SE-0087: Rename lazy to @lazy

Hello Swift community, The review of "SE-0087: Rename lazy to @lazy" begins now and runs through May 23. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md Reviews are an important part of the Swift evolution process.

[swift-evolution] [Review] SE-0077: Improved operator declarations

Hello Swift community, The review of "SE-0077: Improved operator declarations" begins now and runs through May 23. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md Reviews are an important part of the Swift

[swift-evolution] [Review] SE-0050: Decoupling Floating Point Strides from Generic Implementations

Hello Swift community, The review of "SE-0050: Decoupling Floating Point Strides from Generic Implementations" begins now and runs through May 23. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0050-floating-point-stride.md Reviews are

Re: [swift-evolution] Support for coding styles and "swift-format" tool

It would be awesome if Xcode exposed per-file or per-project formatting settings, and could enforce them in the editor. I hope someone from the dev tools group will be able to comment (and help guide the implementation of this) if there are plans for such a feature. Jacob On Tue, May 17, 2016 at

Re: [swift-evolution] Support for coding styles and "swift-format" tool

I would love to see flexible formatting styles be more easily available like this. -Shawn On Tue, May 17, 2016 at 10:33 AM Daniel Martín wrote: > As Swift is getting traction in more and more platforms outside of > Apple, we can expect that many coding styles

Re: [swift-evolution] Winding down the Swift 3 release

> On May 17, 2016, at 3:45 PM, Eric Wing via swift-evolution > wrote: > > So I don’t mind (too much) if it takes longer to get a stable ABI. It > makes my life harder, but on the flip-side, I don’t want to be stuck > with yet another broken language and ABI. I want

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Fri May 13 2016, Nate Cook wrote: >>> On May 13, 2016, at 9:36 AM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> on Mon May 09 2016, Nate Cook wrote: >>> >>> Yet another alternative would be to drop Set and Dictionary down a

Re: [swift-evolution] [proposal] Union Type

That's exactly my point, Sean. - Leonardo On 17 May 2016 at 20:31, Sean Heber wrote: > Cavet: I have not been following this, so probably someone has said this > somewhere and flaws were pointed out. > > I don’t really understand the need for union types when you can have >

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Fri May 13 2016, Joe Groff wrote: >> On May 13, 2016, at 7:30 AM, Dave Abrahams wrote: >> >> >> on Mon May 09 2016, Joe Groff wrote: >> > On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution

Re: [swift-evolution] [proposal] Union Type

Cavet: I have not been following this, so probably someone has said this somewhere and flaws were pointed out. I don’t really understand the need for union types when you can have multiple methods of the same name that differ only by the type of their parameter: func something(value: A) {}

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Tue May 10 2016, Joe Groff wrote: >> On May 6, 2016, at 3:16 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> I am posting this review on behalf of Dmitri Gribenko, Max Moiseev, and >> myself. > >> >> on Tue May 03 2016,

Re: [swift-evolution] [proposal] Union Type

Jiannan, I agree there is an use for union types, I'm just not really fond of the syntax (I'd really prefer something like 'union<...>') and with using it for optionals. To enable this syntax for optionals, None would have to be a valid type of the language and that would enable one to create the

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

> On May 17, 2016, at 5:18 PM, Luis Henrique B. Sousa via swift-evolution > wrote: > > Many thanks, @Maximilian. I'm also not sure about the performance cost, but I > think it is worth it. > So I just updated the proposal also including the additional min/max you

Re: [swift-evolution] Winding down the Swift 3 release

So I don’t mind (too much) if it takes longer to get a stable ABI. It makes my life harder, but on the flip-side, I don’t want to be stuck with yet another broken language and ABI. I want this done right because it will be almost impossible to fix later. Here’s a simple, yet tragic example: BOOL

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

David, I'm thinking about the side effects calling a computed property has and although I see some use cases for let properties I also see workarounds. For example, a lazy initialiser will solve the issue of running a certain code only once and caching its value. I also start to think that any

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

Many thanks, @Maximilian. I'm also not sure about the performance cost, but I think it is worth it. So I just updated the proposal also including the additional min/max you have suggested (thanks once again): https://github.com/apple/swift-evolution/pull/328 Best regards, - Luis On Tue, May 17,

Re: [swift-evolution] SE-0084 spinoff: Newlines as item separators

I don't like this idea so -1 from me. Most languages allow that extra comma at the end of a list and sure that eases reordering a list but making them optional at all lines may make the code confusing to read and put an extra job at the compiler to decide whether a line is a new item or

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

While it is true that it uses min and max, you have to add additional min max in order to achieve the desired behavior. So the implementation should be: (also considering (hopefully all) recent naming/index model updates) // Index is already Comparable extension Collection {

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 17, 2016, at 2:04 PM, Austin Zheng wrote: > > I think this is also probably the best approach. Reskin protocol<> so people > can fix their code when 3.0 hits, and then extend its functionality in an > additive way. > > Joe, given that this counts as part of

Re: [swift-evolution] Could enums have their rawValue type inferred?

Thanks Brent, this one is quite a keeper :). Concise and very friendly way of explaining RawRepresentable. Sent from my iPhone On 17 May 2016, at 21:05, Brent Royal-Gordon via swift-evolution wrote: >> On the other hand: What's the point of "raw-value enums"? Are

Re: [swift-evolution] Enhanced existential types proposal discussion

I think this is also probably the best approach. Reskin protocol<> so people can fix their code when 3.0 hits, and then extend its functionality in an additive way. Joe, given that this counts as part of "generics and ABI", is it acceptable to continue discussion? Or should all of this be tabled

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 17, 2016, at 1:27 PM, Matthew Johnson via swift-evolution > wrote: > > >> On May 17, 2016, at 3:06 PM, Austin Zheng wrote: >> >> I'm honestly not sure it makes sense to introduce a proposal just for >> expressing

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 17, 2016, at 3:06 PM, Austin Zheng wrote: > > I'm honestly not sure it makes sense to introduce a proposal just for > expressing style requirements, and then trying to > retrofit fuller support for other existentials onto it. I would

Re: [swift-evolution] Enhanced existential types proposal discussion

I'm honestly not sure it makes sense to introduce a proposal just for expressing style requirements, and then trying to retrofit fuller support for other existentials onto it. I would prefer that the 'basic package' of existential cases be considered together as a

Re: [swift-evolution] Could enums have their rawValue type inferred?

Oh, this is a really interesting use case for that protocol. I wonder if RawRepresentable might one day be auto-derivable for certain types, as part of a more comprehensive Swift serialization/deserialization feature. Austin On Tue, May 17, 2016 at 1:05 PM, Brent Royal-Gordon via swift-evolution

Re: [swift-evolution] Enhanced existential types proposal discussion

I'm honestly not sure it makes sense to introduce a proposal just for expressing style requirements, and then trying to retrofit fuller support for other existentials onto it. I would prefer that the 'basic package' of existential cases be considered together as a

Re: [swift-evolution] Could enums have their rawValue type inferred?

> On the other hand: What's the point of "raw-value enums"? Are they just a > bridge-technogy, or is it ok to use them to store constants? I think of RawRepresentable (the protocol behind rawValue) as a serialization mechanism, basically the Swift standard library's answer to NSCoding. Thus,

Re: [swift-evolution] Enhanced existential types proposal discussion

Responses inline. Thanks for taking the time to read through and comment, your feedback is incredibly useful! On Tue, May 17, 2016 at 12:41 PM, Matthew Johnson wrote: > > On May 17, 2016, at 1:52 PM, Austin Zheng wrote: > > I put together the

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 17, 2016, at 2:45 PM, Austin Zheng via swift-evolution > wrote: > > Feel free to add as much of this proposal into yours as you want. The trend is towards smaller proposals and introducing change in stages. Since Adrian’s proposal is almost ready it’s

Re: [swift-evolution] Enhanced existential types proposal discussion

Feel free to add as much of this proposal into yours as you want. Austin On Tue, May 17, 2016 at 12:09 PM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > +1 for extending my proposal and making `Any<>` even more a powerful > beast. :) > > -- > Adrian Zubarev > Sent

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

If the value of the property is a constant, shouldn't you just declare it as one? If you have any sort of computation in it, even concatenating two constant strings, can you really say this is a constant? And you would also be overloading the compiler into trying to check for every property you

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 17, 2016, at 1:52 PM, Austin Zheng wrote: > > I put together the skeleton of a proposal detailing enhancements to how > associated types can be referenced in Swift 3+. It's certainly not ready for > submission, but I think it gets across my ideas pretty well.

Re: [swift-evolution] [Idea] if let value!

interestingly enough, it looks like a truly simple task... the grammar has 2 types of BindingKind at that location BK_Let and BK_Var, which means that a single shorthand notation will assume one of the other, which means that if it does assume one, then it better be explicit about it, or

Re: [swift-evolution] Enhanced existential types proposal discussion

+1 for extending my proposal and making `Any<>` even more a powerful beast. :) --  Adrian Zubarev Sent with Airmail Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution (swift-evolution@swift.org) schrieb: I put together the skeleton of a proposal detailing enhancements to how

[swift-evolution] Enhanced existential types proposal discussion

I put together the skeleton of a proposal detailing enhancements to how associated types can be referenced in Swift 3+. It's certainly not ready for submission, but I think it gets across my ideas pretty well. Would love to gather feedback and especially improvements. Be unsparing; whatever form

Re: [swift-evolution] Winding down the Swift 3 release

With semantic versioning, the API changes would require the next version to be called 3.0. The challenge is to not attach stability/maturity ‘feelings’ to semantic version numbers. I don’t think people should attach meaning to Swift being 3.0 any more than they do to Chrome being 50.0 If we

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I really would like to understand what you was trying to tell me. :) My English is a little rusty to understand every piece of someone's thought. By any chance someone could propose your ideas as an enhancement/upgrade of my `Any<>` mechanism later on? I mean like Joe did with removing `.self`

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Sent from my iPad > On May 17, 2016, at 1:02 PM, Douglas Gregor via swift-evolution > wrote: > > >>> On May 17, 2016, at 10:40 AM, Adrian Zubarev >>> wrote: >>> >>> You don’t seem to be tackling the case of “A Collection whose

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Sent from my iPad > On May 17, 2016, at 1:11 PM, Austin Zheng via swift-evolution > wrote: > > I'd like to take a shot at writing such a proposal. At some point improved > existential support will need to go through review, so we might as well. > Really happy to

Re: [swift-evolution] Small Enhancement Request for Swift Protocol

> On May 14, 2016, at 7:49 AM, Sreejith K R via swift-evolution > wrote: > > Hello All, > > > I would like to suggest an enhancement for the swift protocol would really > like this feature to be reviewed. > > Enhancement Description : > > Currently it is not

[swift-evolution] SE-0084 spinoff: Newlines as item separators

[Due to popular demand ;-) in the discussion of SE-0084: Allow trailing commas in parameter lists and tuples] The option to skip semicolons for statements followed by a newline is only a tiny convinience, yet it is one of the most favored differences to C (and one of the most annoying things

Re: [swift-evolution] Winding down the Swift 3 release

I do agree with what you are saying, but in a way it seems to also be saying that the version number set by Apple is a bit rushed. A language reaching 3.0 state and not having nailed down ABI stability sounds a lot different than Swift 0.95 or Swift 1.5 being at the same state and I do not

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> On May 17, 2016, at 10:40 AM, Adrian Zubarev > wrote: > >> You don’t seem to be tackling the case of “A Collection whose Element type >> is String”. If we’re generalizing the current “protocol<>” notion, why not >> make it as powerful as a generic

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

You don’t seem to be tackling the case of “A Collection whose Element type is String”. If we’re generalizing the current “protocol<>” notion, why not make it as powerful as a generic signature, with the ability to specify same-type constraints and conformances on associated types? - Doug

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

It would be useful for clarification of a computed property being constant in extensions. For example: extension SKSpriteNode { static let type: String { return “Sprite” } } Andru ___ swift-evolution mailing list

[swift-evolution] Is SE-0088 (Modernize libdispatch for Swift 3 naming conventions) open for comments?

I see the active review dates of May 10 to 17, but I don’t see any messages about it on here. If comments are welcome at this time, read on. If not, please remind me what the process is (and maybe read on anyway?)! Interoperation: If I have an existing ObjC (or just C) code baae that uses

[swift-evolution] [Idea] "guard not let" optional binding

I've occasionally hit this problem but I don’t think this warrants a language addition, as it can be overcome in other ways. I would move the expensive calculation into its own private method and rewrite your example like this: return cachedValue ?? calculatedValue() In my opinion that would fit

[swift-evolution] Small Enhancement Request for Swift Protocol

Hello All, I would like to suggest an enhancement for the swift protocol would really like this feature to be reviewed. Enhancement Description : Currently it is not possible to invoke the default implementation of a particular protocol (EG: SampleProtocolParent achieved using protocol

[swift-evolution] Support for coding styles and "swift-format" tool

As Swift is getting traction in more and more platforms outside of Apple, we can expect that many coding styles different from what Apple imposes with SourceKit's indenting rules will emerge. According to https://bugs.swift.org/browse/SR-146, we now have decoupled indenting logic from

[swift-evolution] Make access control private by default.

I think internal as default is bad, because it discourages encapsulation. Building scalable software components relies on hiding implementation details to create layers of abstraction. It’s a fundamental principle of object-oriented software design. Most other OOP languages have private

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

I don’t think the API of types have to be bulletproof from the start, but it shouldn’t have core usage limitations based on Objective C. One example would be if I have to deal with NSNumber/NSString/NSArray/NSDictionary to fully use the API, such as NSAttributedString or NSError. The issue is

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> On May 17, 2016, at 6:43 AM, Adrian Zubarev via swift-evolution > wrote: > > So basically everyone start to like by the core team suggested `Any<>` name > of the proposed mechanism. I’ll rename it when I get home. ;) Definitely happy to see this proposal being

Re: [swift-evolution] [Idea] if let value!

A case can be made, of course. My personal opinion is that I don't want to see it in the language at any point. Others are free to agree or disagree. Austin > On May 17, 2016, at 9:21 AM, Matthew Johnson wrote: > > >> On May 17, 2016, at 11:18 AM, Austin Zheng

Re: [swift-evolution] [Idea] if let value!

On 17.05.2016 19:08, Matthew Johnson wrote: it might be worth looking at other aspects of how your code is structured. All is good, if it is in *my* code ;-) But I often see this pattern in *others* code and I don't want to see it in others code :-)

Re: [swift-evolution] [Idea] if let value!

> On May 17, 2016, at 11:18 AM, Austin Zheng wrote: > >> >> If people really want to pursue further sugar here I think it would be >> worthwhile to explore a direction that hasn’t already been debated >> extensively. That is why I suggested thinking about `if unwrap`.

Re: [swift-evolution] [Idea] if let value!

On 17.05.2016 18:58, Matthew Johnson wrote: That said, I really don’t think current state is too bad. It’s definitely not worth expending community energy on this when we clearly have more important things to focus on (like completing generics and ABI). Well.. Although I agree that this is

Re: [swift-evolution] [Idea] if let value!

> > If people really want to pursue further sugar here I think it would be > worthwhile to explore a direction that hasn’t already been debated > extensively. That is why I suggested thinking about `if unwrap`. That said, > I really don’t think current state is too bad. It’s definitely not

Re: [swift-evolution] [Idea] if let value!

> On May 17, 2016, at 11:06 AM, Vladimir.S wrote: > > On 17.05.2016 18:48, Matthew Johnson via swift-evolution wrote: >> Being syntactic sugar for something that is already not too bad > > Well.. Personally I feel like construction `if let someMyValue = someMyValue` > is bad

Re: [swift-evolution] [Idea] if let value!

Regards LM (From mobile) > On May 17, 2016, at 5:48 PM, Matthew Johnson via swift-evolution > wrote: > > >> On May 17, 2016, at 10:41 AM, Brandon Knope wrote: >> >> I always thought a new keyword made more sense here: >> >> if let rebind

Re: [swift-evolution] [Idea] if let value!

On 17.05.2016 18:48, Matthew Johnson via swift-evolution wrote: Being syntactic sugar for something that is already not too bad Well.. Personally I feel like construction `if let someMyValue = someMyValue` is bad exactly because of this the same repeated name. Anywhere I see repeated code,

Re: [swift-evolution] [Idea] if let value!

> On May 17, 2016, at 10:50 AM, Vladimir.S wrote: > > Could you clarify how to use `if case` to achieve the same target as proposed > `if let value!` ? > (btw, probably `if let value? {..}` will be better) You don’t get the same implicit match that this idea proposes, but

Re: [swift-evolution] [Idea] if let value!

It’s not just about being concise, but reducing repeated code: It would be syntactic sugar for this: if case .Some(let optional) = optional { } But yes, unwrap makes much more sense. At the end of the day, I am not too bothered by if let syntax, but if we could clear up some of the

Re: [swift-evolution] [Idea] if let value!

Could you clarify how to use `if case` to achieve the same target as proposed `if let value!` ? (btw, probably `if let value? {..}` will be better) On 17.05.2016 18:18, Matthew Johnson wrote: On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution

Re: [swift-evolution] `once` keyword for use with loops

This only works with the example exactly as-is, I think a fairer re-write would be something like the following: func toCSV(values:[CustomStringConvertible]) -> String { var gen = values.generate() var result = gen.next()?.description ?? "" while let value = gen.next() { result +=

Re: [swift-evolution] [Idea] if let value!

> On May 17, 2016, at 10:41 AM, Brandon Knope wrote: > > I always thought a new keyword made more sense here: > > if let rebind someValue { > //use shadowed unwrapped value in here > } > > if let bind someValue { > //use shadowed unwrapped value in here > } > > >

Re: [swift-evolution] [Idea] if let value!

I always thought a new keyword made more sense here: if let rebind someValue { //use shadowed unwrapped value in here } if let bind someValue { //use shadowed unwrapped value in here } if let unwrapped someValue { } Something along those lines? Brandon > On May 17, 2016,

Re: [swift-evolution] [Idea] if let value!

Now *that* reminds me of the _ voodoo in perl... and i was under the impression that magic symbols are not highly regarded in swift (which I really appreciate!!) Regards LM (From mobile) > On May 17, 2016, at 5:31 PM, Patrick Smith via swift-evolution > wrote: > >

Re: [swift-evolution] `once` keyword for use with loops

> On May 16, 2016, at 11:03 PM, Nicholas Maccharoli via swift-evolution > wrote: > > ​Hello Swift Evolution, > > Its not uncommon to have to do a piece of work only once or on the first > iteration of > a loop. > Take for example producing a comma separated string

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

+1 Missed this one for a long time :) -- Adrian Zubarev Am 17. Mai 2016 um 16:25:10, David Hart via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb: > > +1 Seems like it could enable very powerful behaviour going forward > > > On 16 May 2016, at

Re: [swift-evolution] [Idea] if let value!

FWIW, agreed that more complex guard statements with shorter methods avoid the issue altogether (reminds me of using unless for similar purpose in perl). Regards LM (From mobile) > On May 17, 2016, at 5:15 PM, Sean Heber via swift-evolution > wrote: > > Yep - same

Re: [swift-evolution] [Idea] if let value!

Here’s a idea, what if you could use a symbol to denote that you want the same name used? Here’s an interesting sign from music: https://en.wikipedia.org/wiki/Repeat_sign Then you can write (one) of these: if let |: = mySomeValue { // Use unwrapped } if let mySomeValue = :| { // Use

Re: [swift-evolution] [Idea] if let value!

> On May 17, 2016, at 10:13 AM, Tony Allevato via swift-evolution > wrote: > > While I've sometimes (early on) wished for a shorter-hand syntax for that > construct, I've never been able to think of something that I thought was > better. I've gotten to the point

  1   2   >