Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

[Rob Mayoff via swift-evolution]

On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users <
swift-us...@swift.org> wrote:

>
>
> On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Yes, exactly. An Array is a struct wrapper for a reference type
>> representing storage. Mutating functions first check if they own the only
>> reference to the storage using isKnownUniquelyReferenced
>> .
>> If not, they make a fresh copy before applying the mutating operation.
>>
>> There's no difference for `let` arrays. Access control is enforced at
>> compile-time through Array's design: the compiler will prevent you from
>> calling `mutating` functions on `let` structs, and Array is careful to not
>> expose functionality that could modify its storage outside of `mutating`
>> functions.
>>
>> There is no secret. Anyone could implement the same thing only using
>> publicly available and documented compiler features. In fact, it's been
>> done already for some very powerful collections
>> .
>>
>
> This isn’t entirely true. That BTree module readme seems to contain a lot
> of unsubstantiated hyperbole. It’s possible to implement a classic
> red-black tree in Swift that performs better than a sorted Array, down to
> about *n* = 1,500 items, not *n* = *100,000* items as it claims.
> (Actually, heap allocators these days are good enough that performance is
> on par with Array all the way down to *n* = 1.) Red-Black trees are slow
> when *distributed* as packages because of the crossmodule optimization
> boundary. (This also means the BTree module is much slower than Array for
> most reasonable *n*.) It’s possible to write modules using compiler
> attributes that mitigate this slowdown (reclaiming over 50% of lost
> performance) but it’s hacky and forces you to design your libraries like
> the standard library (meaning: ugly underscored properties everywhere and
> everything is public). And these features aren’t “publicly available” or
> documented at all.
>

This seems harsh. I didn't notice Félix making any claims about BTree's
performance. The necessary API for implementing COW is indisputably public
and documented:

https://developer.apple.com/documentation/swift/2429905-isknownuniquelyreferenced
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

[Rob Mayoff via swift-evolution]

On Tue, Jul 25, 2017 at 4:44 AM, philohan95 via swift-evolution <
swift-evolution@swift.org> wrote:

> As you can see we had to use the properties twice (this would also be the
> case of `if let`) making the initializer twice as long as necessary and
> becomes a pain to implement when having more than 1 property.
>

> My idea is extending the power of the `guard` statement
>
> Idea:
> init?(data: [String: Any]) {
> guard
> someProperty = data["some_key"], // Currently
> fails because `self` us used before all stored properties are initialized
> anotherProperty = data["another_key"]
> else {
> return nil
> }
> }
> }
>

I'm not convinced new syntax is necessary. You can get pretty close to this
today. First, put this in your project somewhere:

struct NilError: Error { }

func throwNilError() throws -> Whatever {
throw NilError()
}

Then use do/try/catch to initialize your properties:

class MyObject {
let someProperty: Any
let anotherProperty: Any

init?(data: [String: Any]) {
do {
someProperty = try data["some_key"] ?? throwNilError()
anotherProperty = try data["another_key"] ?? throwNilError()
} catch {
return nil
}
}
}

It also works for Charles Srstka's example:

let bar: String
if someCondition {
do { bar = mightReturnOptional() ?? throwNilError() }
catch { return }
} else {
bar = wontReturnOptional()
}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Rob Mayoff via swift-evolution]

On Wed, Jun 28, 2017 at 8:49 PM, Ben Cohen via swift-evolution <
swift-evolution@swift.org> wrote:

> As the screener of a non-zero number of radars resulting from unwrapped
> nils, I would certainly appreciate more use of guard let x = x else {
> fatalError(“explanation”) } and hope that !! would encourage it.
>

Sure, but... a lot of unwrap-failed explanations are never going to be
printed because a lot of unwraps will never fail. We're going to spend time
writing those explanations, and we're going to increase the size of our
binaries. Maybe making the bug-screeners do more work is still a net win
for humanity.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Comparison Reform

[Rob Mayoff via swift-evolution]

On Mon, Apr 24, 2017 at 11:44 PM, David Waite via swift-evolution <
swift-evolution@swift.org> wrote:

> I still think this is a naming conflict more than anything else.
>
> The first expectation is that equatable and comparable provides strict
> equality and strict total ordering, and that those are exposed via
> operators. The other expectation is that floating point abides by the IEEE
> rules which have neither of these, and are exposed via operators.
>
> Either:
> 1. the operators need to do different things in different contexts
> 2. we need different methods/operators to indicate these different concepts
> 3. Equatable and comparable need to be altered to no longer require strict
> equality and strict total ordering (and all generic algorithms based on
> equatable/comparable need to be checked that they still work)
> 4. floating point numbers need to explicitly not be equatable/comparable
> to prevent their usage in generic algorithms requiring strict behavior.
> 5. We break away from IEEE behavior and provide only strict equality and
> strict total ordering
>
> (I tried to sort these roughly in order of feasibility)
>
> Are there any other options?
>

Have Double and Float do #5, and new types IEEEDouble and IEEEFloat
implement IEEE behavior and not be suitable for use with generic algorithms
when NaNs are present.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Rob Mayoff via swift-evolution]

On Tue, Mar 21, 2017 at 10:51 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:
>
> The bug *does not affect what people use private for,* and so it *does not
> affect anything in real-world use.* It’s less “the Finder makes your files
> disappear on a regular basis” and more “if you give a file a name with a
> very specific sequence of Plane 2 Unicode characters, and then set the
> ‘Stationery' bit in the Finder flags, the icon doesn’t draw correctly.”
> It’s a bug, and it should be fixed, but it’s not even close to being a
> show-stopper.
>

This, 100%.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Rob Mayoff via swift-evolution]

On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

> A core team member (I'm blanking on who) has pointed out that, in the end,
> the only necessary access modifiers are public and not public (spelled
> "internal" in Swift).
>
>
> It is not clear to me how this squares with the decision in SE-0025 that
> other access modifiers were necessary.  Can you clarify?
>

I believe the reference is to this comment by Slava Pestov on 2017-02-16:

While we’re bikeshedding, I’m going to add my two cents. Hold on to your
> hat
> because this might be controversial here.
>
> I think both ‘private’ and ‘fileprivate’ are unnecessary complications
> that
> only serve to clutter the language.
>


It would make a lot more sense to just have internal and public only. No
> private, no fileprivate, no lineprivate, no protected. It’s all silly.


https://www.mail-archive.com/swift-evolution@swift.org/msg21766.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Rob Mayoff via swift-evolution]

I also disagree with the proposal, and Drew's explanation is spot on.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

[Rob Mayoff via swift-evolution]

On Fri, Mar 10, 2017 at 6:08 AM, Rod Brown via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi everyone. I found something odd that seems baked into how Cocoa Touch
> does protocols, but Swift cannot model it:
>
>
> @interface UIScrollView: UIView
>
> @property (weak, nonatomic) id  delegate;
>
> @end
>
> @interface UITableView: UIScrollView
>
> @property (weak, nonatomic) id  delegate;
>
> @end
>
> @protocol UITableViewDelegate: UIScrollViewDelegate
> ...
> @end
>

The problem here is that `UITableView`'s redefinition of `delegate` is not
type-safe. By casting a `UITableView` reference to a `UIScrollView`, you
set the `delegate` to something that doesn't conform to `UITableView`:

@interface ViewController () 
@end

@implementation ViewController

- (void)viewDidLoad {
[super viewDidLoad];

UITableView *tableView = [[UITableView alloc] init];

// This line correctly generates a warning, because self isn't a
UITableViewDelegate:
tableView.delegate = self;

// This line generates no warning:
((UIScrollView *)tableView).delegate = self;
}

@end
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rob Mayoff via swift-evolution]

On Wed, Mar 8, 2017 at 5:09 AM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> willSet and didSet have their own distinct scope; they execute
> independently, however a switch statement is effectively a single scope
> because of the ability to use fallthrough to visit later cases.
>

A switch statement has a separate scope for every case, including default.
Example:

switch Int() {
case 0:
let m = "zero"
fallthrough
default:
Swift.print(m)
}


Result:

Playground execution failed: error: MyPlayground.playground:2:17: error:
use of unresolved identifier 'm'
Swift.print(m)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rob Mayoff via swift-evolution]

On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Here, a function call is an _intentional_ act. Writing a function not
> meant to be called is an _intentional_ act. It is strange that you would
> demand the compiler to stand between two of your own intentional acts.


Yesterday I stated one intention. Today I (or a coworker) act with a
contradictory intention.

One of these intentions, or some underlying assumption, must be in error.

Why would I want to rely on a human to notice the error, if I can make the
compiler do it?

It is normal to want the compiler to catch my errors. It is strange to
prefer finding errors manually.

You might persuade me that the cost (in language complexity) of having the
compiler detect the contradiction outweighs the benefit.

But I doubt you can persuade me that the detection has no benefit.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Nil-rejection operator

[Rob Mayoff via swift-evolution]

On Thu, Feb 9, 2017 at 2:25 PM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> I wonder if an alternative to the original proposal might be to allow
> throw on the right hand side? So you could do:
>
> let y = x ?? throw myError
>
>
You can do this today:

extension Error {
func throwMe() throws -> R { throw self }
}

let y = try x ?? MyError().throwMe()
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] protocol-oriented integers (take 2)

[Rob Mayoff via swift-evolution]

On Sat, Jan 14, 2017 at 7:41 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

> Oh... you mean that word(at:) itself would be linear, and thus
> algorithms that iterate the words linearly would be O(N^2)...  yuck.
>

Couldn't you fix this by replacing `func word(at n: Int) -> UInt` with `var
words: Sequence`, producing the words from least to most significant?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Allow ' in variable/constant names?

[Rob Mayoff via swift-evolution]

It's not as easy to type, but you can already use U+02B9 MODIFIER LETTER
PRIME for this purpose. Swift accepts this:

let x = 1
let xʹ = x + 1
let xʹʹ = xʹ + 1
let xʹʹʹ = xʹʹ + 1


On Wed, Jan 11, 2017 at 7:08 AM, Tuur Anton via swift-evolution <
swift-evolution@swift.org> wrote:

> I often have related variables. Would be nice to just add ' like I can in
> Haskell:
>
> let foo  = "asdf"
> let foo' = "asdf2"
>
> What do you think?
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rob Mayoff via swift-evolution]

On Thu, Oct 20, 2016 at 9:29 AM, Jonathan S. Shapiro via swift-evolution <
swift-evolution@swift.org> wrote:

> Quick poll as a sanity check on a possible alternative for operators:
>
> If we admitted [:Sm:] and [:So:] and the traditional ASCII operator
> characters, would that cover the things that people currently feel
> passionate about? That would almost certainly be compliant with UAX31 once
> it settles, and I *think* it covers all of the cases people have raised
> here.
>
> Useful links if you want to check:
>
> [:Sm:]  Symbol, Math
> 
>
> [:So:]   Symbol, Other
> 
>
>
This would define both ∞ and ∅ as operators.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rob Mayoff via swift-evolution]

On Wed, Oct 19, 2016 at 10:47 AM, plx via swift-evolution <
swift-evolution@swift.org> wrote:

> In any case, I’d specifically hate to lose these:
>
> - approximate equality: ≈
> - set operations: ∩, ∪
> - set relations: ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋
> - set membership: ∌, ∋, ∈, ∉
> - logical operators: ¬, ∧, ∨
>

I'd add ≤ ≥ ≠ to that set.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

[Rob Mayoff via swift-evolution]

Just to be clear, under your proposal, what does the following program
print? Can you make an argument in favor of your interpretation?

var x = 1
switch x {
case 1:
print("one")
x = 2
continue
case 2:
print("two")
default:
break
}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Removing Variadic Parameters.

[Rob Mayoff via swift-evolution]

On Wed, Jul 6, 2016 at 2:57 PM, Tino Heth via swift-evolution
 wrote:
> Can you talk about concrete examples? Because Objective-C had no variadic 
> messages, it's natural that the feature isn't utilized in Cocoa

Objective-C has variadic messages. I'd be surprised if any seasoned
Objective-C developer hasn't used `+[NSString stringWithFormat:]`.

These are most of the variadic messages in the El Capitan SDK:

-[NSGradient initWithColorsAndLocations:]
-[AMAction logMessageWithLevel:format:]
-[CIFilter apply:]
+[CISampler samplerWithImage:keysAndValues:]
-[CISampler initWithImage:keysAndValues:]
+[NSArray arrayWithObjects:]
-[NSArray initWithObjects:]
-[NSCoder encodeValuesOfObjCTypes:]
-[NSCoder decodeValuesOfObjCTypes:]
+[NSDictionary dictionaryWithObjectsAndKeys:]
-[NSDictionary initWithObjectsAndKeys:]
+[NSException raise:format:]
-[NSException handleFailureInMethod:object:file:lineNumber:description:]
-[NSException handleFailureInFunction:file:lineNumber:description:]
+[NSExpression expressionWithFormat:]
+[NSOrderedSet orderedSetWithObjects:]
-[NSOrderedSet initWithObjects:]
+[NSPredicate predicateWithFormat:]
+[NSSet setWithObjects:]
-[NSSet initWithObjects:]
-[NSString stringByAppendingFormat:]
-[NSString initWithFormat:]
-[NSString initWithFormat:locale:]
+[NSString stringWithFormat:]
+[NSString localizedStringWithFormat:]
-[NSString appendFormat:]
-[SBObject  sendEvent:id:parameters:]
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Shorthand unwrap proposal

[Rob Mayoff via swift-evolution]

This is equivalent to the “Add an ifPresent function to Optional”
suggestion made back in March.

http://thread.gmane.org/gmane.comp.lang.swift.evolution/9173

Personally I'd prefer an `ifPresent` or `foreach` method to using
`map`, as `ifPresent` or `foreach` would make it clearer to the reader
that no return value is expected or wanted from either `ifPresent` or
the block it calls.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal SE-0009 Reconsideration

[Rob Mayoff via swift-evolution]

On Mon, May 23, 2016 at 12:26 PM, David Sweeris via swift-evolution
 wrote:
> Dunno about other IDEs, but Xcode's syntax highlighting can change the size, 
> typeface (bold, italic, etc), and even the font. You can make instance 
> variables show up as 24pt comic sans, if you want. You can’t do polkadot, 
> though… apparently that’s going too far.

Unfortunately, doing this can trigger a longstanding Xcode bug that
makes it very difficult to edit any file that's substantially longer
than the height of your window.

http://stackoverflow.com/questions/26761295/xcode-6-code-editor-erratic-behaviour
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rob Mayoff via swift-evolution]

We (you) shouldn't remove the NS prefixes from most of the classes in
the proposal. I agree with the reasons the other naysayers have given,
but I'll try to restate them in my own words.

Swift needs a better namespace/import system before these classes
should lose the NS prefix. Right now, you cannot just import one name
from a module. (If you think you can, try typing “import
Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be
selective about what loses the NS prefix.

For any type, some fraction of programs need to mention the type by
name in order to justify a prefixless name. What should that threshold
be? Fifty percent? Ten percent? Five percent? String and Int and a
bunch of other types in the standard library can pass a reasonable
threshold. What fraction of programs mention NSTask? NSPort? NSHost?
NSScanner?

For any name, some fraction of programs would want to use that term
for a program-specific type different than the Foundation type. What
fraction is high enough to justify prefixing the Foundation type name?
E.g. are there enough datebook programs that think "Calendar" should
mean the user's schedule of events, so that Foundation shouldn't claim
the generic term "Calendar"? How about "Timer"? "Task"? "Port"?
"Host"?

What fraction of these Foundation types would have a substantially
different API if they were designed from scratch in the age of Swift
with the experience of Foundation? Example: NSDate. Looking at each of
JodaTime, NodaTime, and boost::date_time, I see a type representing a
calendar date (e.g. 2016-05-16) with no associated time of day. I've
seen and answered enough questions on stackoverflow to know that iOS
programmers want a type like that. A from-scratch Swift date/time
library would be justified in having such a type, and "Date" would be
a great name for that type (with a prefix or nested in another type,
unless Swift gets a better namespace/import system). NSDate represents
the same thing as CFAbsoluteTime, and should have a name more
representative of that.

I just don't see the benefit of stripping the NS prefix from most of
the types in Foundation, given the state of those types and the state
of Swift.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

[Rob Mayoff via swift-evolution]

(-1)^sign * significand * radix^exponent

Significand is not like the other two, I guess, since nothing is raised to
it as a power...

On Fri, Apr 22, 2016 at 11:42 AM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
>  A floating point number is made up
> of three parts, and one part *is* not like the other ones.  Furthermore,
> using an enum doesn't change that one (ahem) bit.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

[Rob Mayoff via swift-evolution]

>
>
> class UITableView {
> ...
> private func addRow(at indexPath: NSIndexPath) {
> ...
> cell.size.height = delegate?.tableView(self,
> heightForRowAtIndexPath: indexPath) ?? rowHeight
> ...
> }
> ...
>

You need not duplicate the default logic:


private class DefaultDelegate: NSObject, UITableViewDelegate { }
private let defaultDelegate = DefaultDelegate()

public class UITableView {

private func addRow(at indexPath: NSIndexPath) {
...
cell.size.height = (delegate ?? defaultDelegate).tableView(self,
heightForRowAtIndexPath: indexPath)
...
}

}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next

[Rob Mayoff via swift-evolution]

Check out the `testable` attribute:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Attributes.html#//apple_ref/doc/uid/TP40014097-CH35-ID347

Lots of examples if you type `swift testable` into your favorite search
engine.

On Fri, Apr 1, 2016 at 4:04 PM, John Heerema via swift-evolution <
swift-evolution@swift.org> wrote:

> I’m a fan of test-driven development.
> I use it myself, and teach it to students and colleagues.
>
> One of the nice things about Swift 1.0 was that it was easy to write
> module tests.
>
> When access controls were introduced into Swift, I found that many
> functions and objects that had no genuine need to be public, suddenly had
> to become public in order to be tested. That just seems wrong to me.
>
> I’d like to see a way for tests, which are not normally part of the
> module, to have access to a module’s contents (I’m talking source only –
> not packages that do not include source). That might simply be a feature of
> the IDE, rather than a language feature.
>
> On another note, I see “file private” (whatever it’s called) as a legacy
> of C. I have trouble seeing it as being truly useful, but can see that
> others might have genuine uses for it (actually, I’d like to hear what they
> might be)
>
> Thanks,
> Dr. J. Heerema
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

[Rob Mayoff via swift-evolution]

I would prefer the conditional statements to treat trailing closures
consistently, rather than allow this minor but inconsistent convenience. I
don't think this needs changing. I read the proposal and followed the list
discussion.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [proposal] Allow trailing closures in 'guard' conditions

[Rob Mayoff via swift-evolution]

 I think there will be confusion if these statements are inconsistent
regarding trailing closures.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

[Rob Mayoff via swift-evolution]

Option 2i is the only one that neither discards nor makes up information,
and it doesn't seem like 2i would impose a significant burden on users.​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

[Rob Mayoff via swift-evolution]

Great idea, but why make it a free function instead of a Selector
initializer?

let sel1 = Selector(UIView.`insertSubview(_:at:)`)
let sel2 = Selector(UIView.`frame.get`)

Of course if there were such a thing as
GeneralizedFunctionNameLiteralConvertible, we could get a “free” conversion
to Selector:

control.sendAction(MyTarget.`doSomething(_:)`, to: target, forEvent:
event)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Enum 'count' functionality

[Rob Mayoff via swift-evolution]

On Tue, Dec 22, 2015 at 12:33 AM, Zef Houssney via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree with Stephen Celis that the best names for this (yet) are
> definitely `cases` and optionally `rawValues` if the cases are
> RawRepresentable.
>

That makes me want to say `for case in SomeEnum.cases { ... }`, which is a
syntax error, as opposed to `for value in SomeEnum.values { ... }`, which
is legal.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

[Rob Mayoff via swift-evolution]

When you access a static member of a type using the dot shortcut, Swift
evaluates the expression immediately.

Are you proposing that when you access a member of an instance, Swift
generate a closure?

Or are you proposing that Swift generate a closure or not depending on how
the expression's value is to be used?

Either way seems inconsistent with the static member situation, and like a
potential source of confusion: not everyone uses the One True Convention™
of .Capitalized .Static .Members and .lowercase .instance .members, so one
cannot reliably deduce the outcome based on the case of the character after
the dot.

On Thu, Dec 17, 2015 at 9:27 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

> anArray.map{$0.anInstanceMethod()}
>
> becomes:
>
> anArray.map(.anInstanceMethod())
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution