The main advantage is not in this change by itself, but in the fact that it
tidies up the syntax and makes it easier to support other additive proposals in
the future that might make better use of the colon syntax— such as targeted
continue statements in `switch` or a `switch` expression syntax.
I think the discussion on this has run its course and it sounds like there’s
mixed feelings, but it’s mostly a matter of opinion between consistency and
“ugliness”. As I understand it, the “socialization” process isn’t meant to
reach consensus, but to hone the proposal (or abandon it if the fee
+1
Personally this one wouldn’t bother me to require, but It seems the Swift way
is to not require things that can be inferred by context so I’m ok with just
allowing it.
> On Jul 11, 2016, at 9:03 PM, Jacob Bandes-Storch via swift-evolution
> wrote:
>
> Currently, "infix" is not required/al
I understand that it’s only one function and that I’m probably being
ever-so-slightly unreasonable but I’ve spent the last month going crazy that a
language as expressive as Swift, with all of its support for protocols and
generics and under-the-hood optimization, makes me do stuff like this to
For certain functions (sqrt, sin, cos, log, etc) we’ve grown up in math class
calling them as a function on an argument rather than viewing them as a
property (or method) of the number.
Just like we prefer to use `a - b` rather than `a.sub(b)`, we (or at least I)
prefer `sqrt(a)` over `a.square
While I don’t have a strong opinion about what functions are in the global
namespace and which are in a `Math` module, I’m not excited about the idea of
delaying the availability of generic implementations of floating point
functions.
How would this affect code intended to operate generically o
I like this idea.
Remember that `continue` can typically take an optional argument that allows a
type of “goto” functionality. Would it work to allow the `continue` target to
be a labeled `case`? This could allow for some rather sophisticated logic
without needing to duplicate a lot of code a
The discussion so far has given me a chance to organize my thinking, so here’s
a more complete train of thought.
I get that people don’t like extra punctuation. The commonly rejected
proposals, however, make it clear that braces are here to stay and we should be
designing the syntax right now
I feel like there are two totally different discussions happening here. One is
whether Swift needs better interoperability with C++, which it does. Let’s
just assume that that will happen.
The other discussion, which I think was the intended topic of this thread, is
whether the benefits of pa
I would very much like to see this. Perhaps not Metal per se, but the ability
to compile code to a heterogenous architecture.
I’ve been mulling two sets of ideas that might be steps in that direction:
— making the simd.h types (double4, float2, etc) first class types in Swift
— introducing the
d values?
>
> In general, +1 for simplifying the syntax, but I'm not sure it'd work well,
> given that enums take on a larger roll in Swift than they do in other
> languages. Or maybe it'd be fine... I'm just too tired to picture it in my
> head.
>
>
ains but I generally have 2+ cases which
> would result in more braces than my typical if-else
>
>> On Jul 7, 2016, at 4:41 PM, G B via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> The same can be said for if/else constructs though— al
.
> On Thu, Jul 7, 2016 at 15:31 Roth Michaels via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
> On Thu, Jul 07 2016 at 04:07:06 PM, G B via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
> > I feel like this would be more consistent
The same can be said for if/else constructs though— all those braces get heavy
if they’re all wrapping one line each. Python does away with the braces and
relies on indentation, but Swift has explicitly stated that it will not follow
that path— yet case statements seem an exception. It’s a col
It has always seemed odd to me that `case`s use a colon as a delimiter rather
than curly braces like everything else. Is there a reason for this other than
the legacy of C-like languages?
If I wanted to write a series of branching `if` \ `else` statements I would do
it like so:
if x==0
15 matches
Mail list logo
