Re: [swift-evolution] [External] Re: [Pitch] Replace the ternary operator with an in-language function

On Oct 26, 2016, at 11:54 AM, Haravikk via swift-evolution wrote: >> >> Bottom line, most developers know the ternary expression if they come from >> C, C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be >> different for style reasons. We will be

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

David, you can use two binary operators (or overload the same one twice if you want) to create syntax that behaves like a ternary operator. Here’s an example of using a pair of operators to interpolate between two CGPoint values: let interpolatedPoint = p1 <~~ 0.3 ~~> p2 See here

[swift-evolution] [Pitch] Expanded type category constraints

Do we already have a proposal for expanding constraints to support categories beyond class? I am guessing this might have ABI stability concerns, or at least library resilience concerns. If so and no one else has tackled it I’m happy to write up a proposal. There are only a couple that I know

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

> On Oct 25, 2016, at 23:51, Charlotte Angela Tortorella via swift-evolution > wrote: > > Disadvantages of The Ternary Operator > > [...] > > 6. This operator is only applicable to a single type, `Bool`. > > [...] > > Proposed Approach > > We should drop the

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

> On Oct 24, 2016, at 22:33, Chris Lattner via swift-evolution > wrote: > would it be possible to carve off some obvious blocks of emoji support as > identifiers (e.g. not symbols, flags, or anything else complicated), and > carve off the most obvious blocks of the

Re: [swift-evolution] guard let x = x

First off, Chris made it clear dealing with this isn't a priority for Swift 4 so take my comments (inline below) with a grain of salt. At least for the time being this horse should Rest In Peace. > On Oct 26, 2016, at 11:58 AM, Erica Sadun wrote: > > >> On Oct 26,

Re: [swift-evolution] [External] Re: [Pitch] Replace the ternary operator with an in-language function

> On 26 Oct 2016, at 18:57, Jon Akhtar via swift-evolution > wrote: > > I think that we need to get past the “leftovers from C” being a bad thing > mindset. Familiar constructs make Swift easier for programmers (its target > audience) easier to learn. > > Point by

Re: [swift-evolution] [External] Re: [Pitch] Replace the ternary operator with an in-language function

Very well said, thanks :)! Sent from my iPhone > On 26 Oct 2016, at 18:57, Jon Akhtar via swift-evolution > wrote: > > I think that we need to get past the “leftovers from C” being a bad thing > mindset. Familiar constructs make Swift easier for programmers (its

Re: [swift-evolution] [External] Re: [Pitch] Replace the ternary operator with an in-language function

I think that we need to get past the “leftovers from C” being a bad thing mindset. Familiar constructs make Swift easier for programmers (its target audience) easier to learn. Point by point: 1. Being a holdover from C isn’t a bad thing. We can take things that were useful in C and make

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 10:23 AM, Joshua Alvarado > wrote: > > In your example the keyword only makes sense if you are shadowing the > optional variable. How would unwrap work with a different name? It wouldn’t: “unwrap” would never include an equal sign. If you

Re: [swift-evolution] guard let x = x

In your example the keyword only makes sense if you are shadowing the optional variable. How would unwrap work with a different name? Ex: guard let bar = foo else {...} guard unwrap bar else {...} -> There is no context to what the guard is unwrapping This could end up leading to: guard unwrap

Re: [swift-evolution] guard let x = x

On Oct 26, 2016, at 9:37 AM, Chris Lattner via swift-evolution > wrote: To me, this is the most promising direction, but I’d suggest the use of “unwrap" as the keyword. If you compare these two: a) guard let foobar = foobar else { …

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

You and I discussed this at length in iOS Folks, but I'll restate here. I'd be against this proposal. I think it adds unnecessary verbosity vs a simple and elegant representation. As an inherently functional alternative to if-then-else, Swift's ternary form is clear and parsimonious, perfect

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

Training users to expect source-breaking churn would be highly damaging to > the language. The removal of C-style for loops and increment/decrement > operators came with sufficient justification beyond their being inherited > from C. I don’t think there’s a sufficient justification for this

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

> On Oct 26, 2016, at 9:12 AM, Mark Sands via swift-evolution > wrote: > > Strong +1 from me. > > This simply feels like the right approach for Swift, as we see the language > head in a direction that has abandoned traditional C-style idioms. As swift > has

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

On Oct 26, 2016, at 1:11 AM, alessandro aresta wrote: > Ensure is more comprehensible, guard is for sure "always" been there in older > languages... could it be kind of aliased somehow? I tend to confuse guard > sometimes, despite many few decades of using it. No, we

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 8:58 AM, Erica Sadun via swift-evolution > wrote: >> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution >> > wrote: >> >> Hey all, >> >> As usual, apologies if this horse

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

> On Oct 26, 2016, at 2:32 AM, Adrian Kashivskyy via swift-evolution > wrote: > > I’m -1 as it’s currently written, for the following reasons: > > 1. Differences are introduced to pattern matching in different parts of the > language (`switch` vs `if`/`guard` vs

Re: [swift-evolution] guard let x = x

> On Oct 26, 2016, at 5:40 AM, David Goodine via swift-evolution > wrote: > > Hey all, > > As usual, apologies if this horse was beaten ages ago before I joined the > mailing list, but thought I would bring this up. > > I was typing the above (for the hundredth

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

-1 I love the idea of challenging the syntax but without any real benefit I can see it harder for new devs and it will cause breaking changes that doesn't outweigh the cause. The syntax z ? x : y is not hard to comprehend and expresses powerful statements in just a simple line. I do agree it

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

Strong *+1* from me. This simply feels like the right approach for Swift, as we see the language head in a direction that has abandoned traditional C-style idioms. As swift has already dropped support for the ++/-- operators and C-style for loops it makes logical sense that dropping the ternary

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

I like the idea in theory, but I also like the existing ternary operator. Could some of this be accomplished without drastic changes? Some alternative ideas- 1) Codify ternary operator declaration in the language, but make some common-sense restrictions to reduce expression parsing complexity

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

I'm a +1 on the basis that I wasn't even aware of the first case, so have never used it! Although I've used clone methods and such in the past, I've always done so with the generics specified so never noticed that I could omit them, however I do frequently run into the unexpected case that this

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

-1 as well, particularly agreeing with Rimantas that removing something of use because it confuses new programmers is not a good motivation. To paraphrase Einstein, “A programming language should be as simple as possible, but no simpler.” -d > On Oct 26, 2016, at 6:26 AM, Rimantas Liubertas

[swift-evolution] guard let x = x

Hey all, As usual, apologies if this horse was beaten ages ago before I joined the mailing list, but thought I would bring this up. I was typing the above (for the hundredth time) the other day and I was wondering whether it might be worth considering offering a shorter syntax: guard let x,

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

> > Pitch: I'd like to simplify the syntax, compiler complexity and learning > curve for newcomers when it comes to dealing with the ternary function. The > best way to do that, in my opinion, is to remove it entirely and add a new > function with better semantics that takes care of ternary

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

> This proposal replaces the current syntax with a simpler grammar that > prioritizes pattern matching but mirrors basic conditional binding. The new > syntax drops the case keyword and replaces = with ~=. The results look like > this: > > guard let .success(value) ~= result { ... } > guard

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

infix operator ♠️ : LogicalDisjunctionPrecedenceinfix operator ♥ : LogicalDisjunctionPrecedence func ♠️(lhs: Bool, rhs: @autoclosure () throws -> T) rethrows -> T? { if lhs { return rhs() } else { return nil } }func ♥(lhs: T?, rhs: @autoclosure () throws -> T) rethrows -> T { return lhs ??

Re: [swift-evolution] [Pitch] Simpler interpretation of a reference to a generic type with no arguments

I vote to incorporate it somehow into the “Universal Self ” proposal. – Adrian___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

I’m -1 as it’s currently written, for the following reasons: 1. Differences are introduced to pattern matching in different parts of the language (`switch` vs `if`/`guard` vs `for`). 2. Exclusion of `for` in the proposal is either deliberate (which relates to point 1.) or done as a result of a

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

> On Oct 25, 2016, at 9:51 PM, Charlotte Angela Tortorella via swift-evolution > wrote: > > Preamble: I've read over the threads that already exist about the ternary > operator and to be honest they're a complete mess without a single fully > formed proposal. >

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

Ensure is more comprehensible, guard is for sure "always" been there in older languages... could it be kind of aliased somehow? I tend to confuse guard sometimes, despite many few decades of using it. On Wed, Oct 26, 2016 at 2:52 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

Sent from my iPhone > On 26 Oct 2016, at 06:56, Charlotte Tortorella via swift-evolution > wrote: > > Hi Chris, > > I see, well with that in mind the proposal does set out how ?: is harmful to > comprehension of code for new programmers and I hope the pros and