There’s no suggestion of getting rid of the ExpressibleByDictionaryLiteral
> capability.
>
> “Ceci n’est pas une literal”
> - Magritte
>
> On Jan 9, 2018, at 8:26 PM, Charles Constant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Nevin (et al)
>
>
Hi Nevin (et al)
Here's the relevant section of my code. It's from a protocol I use called
"ParameterSet" to extend OptionSets to contain small numbers (like an Enum
with an associated type, but all the data is stored in the UInt). Wouldn't
be my first choice to share, as it breaks KISS. Anyhow,
The disadvantage is that it's easy in Swift to push millions of things in
protocols, and end up with:
class MyClass: SwiftProtocollable, MoreFunctionalityable, MoreHereable,
StillMoreable, ThisTooable, StillMoreable {
...
}
Given enough thought, maybe this can be avoided, but the
> Having one import per line is much more readable and maintainable
This depends on how much importance you give to "import" declarations. If
you feel they equally important as the rest of your code, I can understand
why you would want to see them. I don't.
My preference is to see as much of the
How would we all feel about allowing multiple modules with one import
statement?
Eg: the option to write
*import Cocoa, Foo, Bar.Baz *
in addition to just:
*import Cocoa *
*import Foo *
*import Bar.Baz *
When I'm writing smaller files that import a few modules, I'd
+1 for me for "in-module" as a stop-gap, since I imagine it would be the
quickest, and least disruptive, way to make this happen.
I would add the caveat that if we do so, I really hope we commit to making
stored properties available *everywhere* later.
Even though it's more often than not
Does anyone else think we should allow assignment to self in Class
"convenience init" methods?
Ie: this is legal for a struct, but complains about self being immutable if
you try it in a Class, even if it's a convenience init:
init( foo:String ){
self = Me( bar:foo )
}
I haven't
I actually prefer "fileprivate" to the alternatives, but imo using the word
"private" is a bad choice for this, since it's basically a relative term.
If we're going with parens "visibility(file)" makes more sense to me.
On Fri, Oct 7, 2016 at 5:00 AM, Georgios Moschovitis via swift-evolution <
-1 for me, but...
> I’m aware of how associated objects work, I’m not aware of why they are
particularly useful in Swift
If stored properties in Extensions aren't useful, why would anything else
in an Extension be useful either? I gather there are reasons it is
impractical to implement them, but
The date I can submit my Swift 3 app to the App Store has significant
impact on my life at the moment. I think Chris' meaning was actually fairly
clear, but I'd also appreciate if the team could spell out an ETA again in
black and white. I'd like to be 100% sure I didn't misunderstand.
On Sat,
A single member version of this could be useful, too. Has anyone else here
ever found themself trying to think of an argument label for an init
method, just to ensure it has a unique signature? This would be handy:
*extension Foo {*
*convenience init( _ kind:(.DiskBased) ){*
*
An enthusiastic +1 to Erica's suggestion.
While I also see the appeal of Chris Kornher's suggestion of giving the
enum a proper Type, I think Erica's syntax is more appropriate. I haven't
though through the implications of having an "anonymous enum" but since the
main use case is just to give
It did occur to me to use "::" but it seemed a bit cruel to have the
equivalent of "? :" be reversed. Ie: by using ":: ??" If the team had
chosen :: to be the Nil Coalescing Operator, rather than ?? it would be
more tempting.
I had some problems messing around with these symbols. I think it was
my desktop I'll add a couple better examples of what I'm
> proposing.
>
> Sent from my iPhone
>
> On May 23, 2016, at 6:18 PM, Dany St-Amant <dsa@icloud.com> wrote:
>
>
> Why reinvent the wheel, when the old trusty (but a bit cryptic according
> to some) tri-op ca
couldn't be more embarassed.
But I'm happy too, because I can go ahead and just use a chained ternary.
Sorry all, and thanks.
On Mon, May 23, 2016 at 6:26 PM, Dany St-Amant <dsa@icloud.com> wrote:
>
> Le 20 mai 2016 à 07:14, Charles Constant via swift-evolution <
&g
Correction. My example reused "val" This is what I should have typed:
*let foo = *
*"positive" where ( bar > 0 ) ?? *
*"negative" where ( bar < 0 ) ?? *
*"zero"*
Sorry for that. My mind seems to switch itself off whenever I submit to
this list :)
Also, since my
Would this still be an issue if switch statements were less verbose? I
don't see why a "switch" statements should be so much more verbose than an
"if statement".
Writing boiler plate for switch statements is by far my #1 irritation at
the moment (now that argument labels have been made beautiful
I can't stop fiddling around with this... so here's another minor
variation. My new new favourite, if we're doubling down on the ternary.
We could start with Paul's ternary example... but it seems more in keeping
to me, with the existing ternary, to use a colon as a separator. If we do
that, an
I support this, not because I find NS- and CG- geometric structs confusing.
I support it because I'm hoping Swift library versions would be generic. I
would be very glad to see us get *Rect* or *Point* as part of
the standard library.
On Wed, Jan 6, 2016 at 9:32 PM, John Randolph via
Alex,
We know, from the traditional ternary, that a colon is going to satisfy the
requirements of a separator, even when we want to chain.
Is this the case with bar "|"? To me, this doesn't bode well
let a = b ?
2 : 3 |
4 : 5 |
_ : -1
Above, are we talking about a result of "3
Hi Paul,
My opinion, atm, is that ":" as a separator is the best solution. True,
it's not *Swift-like*, but neither is the existing ternary, which Chris
wants to keep. On then other hand, "colon as separator" is extremely
*ternary-like*.
So benefits of "colon as separator" as I see them:
-
> I see what you are trying to do, because of the colon being both used for
switch cases and
> separators for the ternary and so there needs to be a new character for
each case.
> I am not sure that putting colons between each case is really necessary
though.
Most of us (including you and I) like
t;
> ternary was likely used originally because they could not think of
> something better - but at least it is easy on the tongue…. [composed of 3
> parts]
>
> regardless of syntax - maybe just call it a “match expression”.
>
>
> On 2016-01-07, at 10:06:46, Charles Constant via
Our ternary-like switch is now in the "commonly_proposed.md" file, which
doesn't bode very well. It puzzles me that there isn't more enthusiasm. Are
we the only ones who get irritated taking up so much space with a "switch"
when all we need to do is transform between two sets of values?
I think
My best guesses here, since I didn't write and don't entirely agree...
*> Please detail what the trade offs are*
Other than more complexity, I think this refers to making the "switch"
statement do two slightly different things. Of course, if we call it
something else, like "match" or "which"
I'm with Matthew/Craig.
We discussed a couple very ternary-like versions earlier in the thread,
which I increasingly think are the best options.
The major objection to this came from Lattner, and his objection, if I have
it right, is "this proposal doesn't add enough functionality to justify the
> In the case where your input is hashable, you could just do:
>
> let i = [.Red:0xff, .Green:0x00ff00, .Blue:0xff][color]
You forgot to declare the type, which is mandatory if you want to use
abbreviated cases like ".Red" to construct a one-off like that. That's one
of the reasons I
> In the case where your input is hashable, you could just do:
>
> let i = [.Red:0xff, .Green:0x00ff00, .Blue:0xff][color]
Mea culpa: you were correct, this actually *does* work in a Playground, as
long as you access it when you construct it.
I didn't realize Swift was smart enough to
When I started using Swift, and wanted to learn the syntax for closures, I
found the "in" token very confusing. I probably would have figured it out
at least a half hour sooner, if it had been a different word, or an
operator. I kept thinking "that can't be right, I must be misinterpreting
the
> just not sure weather it would be good to put more complexity into Xcode
Braceless mode is sort of a special case. It could be useful, even for
people prefer braces, to temporarily hide some of the more, uh, decorative
elements - and vice versa.
The option to switch back and forth, for
Andrey's post encourages me to veer into the merits of significant
whitespace vs braces. This is probably unwise of me, since we're not all
going to agree any time soon, but I can't resist pointing out an example:
var foo:
Yes, that is the point. If you use braces in Swift, you will naturally
gravitate to all sorts of personalized strategies. Now this is possible
with significant whitespace (e.g.: Python uses the semicolon to put
multiple statements on the same line) but not nearly as common.
On Sun, Dec 20, 2015
g?
On Sat, Dec 19, 2015 at 7:52 PM, Charles Srstka <cocoa...@charlessoft.com>
wrote:
> On Dec 19, 2015, at 9:43 PM, Charles Constant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> I noticed several weeks ago that the following is illegal:
>
>
This entire thread is just beating dead horse. Having said that; why not
allow braces for closures, and disallow them elsewhere? It doesn't seem
like a deal-breaker, really. I don't think there's much to debate aside
from this: some people worry that significant whitespace makes code more
I noticed several weeks ago that the following is illegal:
let new_arr = el in arr where el.is_foo // illegal
I assumed it would work because it's consistent with the filtering that
exists in a "for" loop, i.e.:
for el in arr where el.is_foo // legal
Is this "new proposal" material? I
+1 fwiw
Grr, I hate braces so much I can't even... but I've seen this discussed on
the Apple dev forums. It's not going to happen. I think the best we (those
of us who dislike braces) can ever hope for is that Xcode gives us a way to
view our code in the IDE as though braces didn't exists - even
36 matches
Mail list logo
