Huge +1. Every time I work with collections, I read the type signatures to be
100% on whether a method will mutate in place or not. I don’t trust the names
as they’re not consistent.
R+
Sent from my iPhone
> On 3 Nov 2017, at 02:58, Xiaodi Wu via swift-evolution
> wrote:
>
>> On Thu, Nov 2,
+1
A simple “discardable” would be great. If the result is Bool and “discardable”
is placed right in front of it, it’s not only more readable but also eliminates
the redundant word “Result”. Also no at sign is great.
Plus, this is super-straightforward to convert for the compiler when upgrading
This is a great proposal.
However, it can make unit testing problematic. Let me explain.
In my unit tests, I often add initializers that set stored properties directly
to create structs with desired data and those are then fed into the struct
that’s under test. This is to test in complete isola
This is fantastic news! Any chance of this landing in Swift 4.x instead of 5?
R+
> On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution
> wrote:
>
> Proposal Link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
>
> The review of
Xiaodi,
thank you for your time and very thoughtful replies!
You’re right, there’s no way around teaching integer arithmetic as it applies
to many other cases, e.g. 2 / 3 == 0.
Happy coding and thanks again!
R+
___
swift-evolution mailing list
swift
> On 22 May 2017, at 14:18, Xiaodi Wu wrote:
>
> What are the "subtle bugs all over the place" that you observe, and what did
> those users expect to happen?
They pretty much universally expect the value to be rounded. When this happens,
I tell them about this language called C (… insert long
On 17 Apr 2017, at 01:46, Riley Testut wrote:
>
> So while you personally may not use extensions, calling the use of them
> "spaghetti code" is rather misguided IMO.
You’re right, I overgeneralized. Let me correct myself:
From what I’ve seen so far [*], using extensions for "code organization"
> On 17 Apr 2017, at 00:46, David Hart wrote:
Reply below.
> And it's a style that is so widely used by the Swift community that even if
> you think it's a bad practice does not change the fact that many people use
> that style and that the current access level rules don't play well with them.
:42, Derrick Ho wrote:
>
> Rudolf, I don't believe that is a rule.
>
> One example includes NSLog()
>
> In which the first parameter is a format string and the second is a variadic
> argument. The second one can be omitted.
> On Wed, Mar 8, 2017 at 5:09 PM Rudo
Correct me if I’m wrong but a variadic argument is guaranteed to have one or
more elements in the array. Isn’t that the case? As an example, consider the
following initializer:
public init(state: State, actions: Action...) {
// ...
}
Here, I can count on actions to be a non-empt
+1 for either e-mail or GitHub issues. No need for yet another tool...
R+
> On 28 Jan 2017, at 01:21, Karl Wagner via swift-evolution
> wrote:
>
>
>> On 27 Jan 2017, at 02:10, Derrick Ho via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> I'm surprised there is so little
#function takes no arguments.
>>
>> There's no way to get #selector for the current method. And there’s no way
>> to get #function for arbitrary method.
>>
>> R+
>>
>>> On 14 Nov 2016, at 20:07, Jordan Rose >> <mailto:jordan_r...@apple.com>&
t sure if that makes it reasonable.
> :-) What’s your use case? The stripped-down code seems like it could use any
> unique key, including #function.
>
> Jordan
>
>
>> On Nov 13, 2016, at 15:50, Rudolf Adamkovič via swift-evolution
>> wrote:
>>
>> Hi
> On Nov 13, 2016, at 6:50 PM, Rudolf Adamkovič via swift-evolution
>> wrote:
>>
>> Hi there!
>>
>> in Swift 3, we now have #selector and #keyPath yet there’s still no _cmd
>> like we have in Objective-C.
>>
>> Example:
>>
Hi there!
in Swift 3, we now have #selector and #keyPath yet there’s still no _cmd like
we have in Objective-C.
Example:
class DirectoryListingStub: DirectoryListing {
var cannedOutput: [Selector: Any?] = [
#selector(contentsOfDirectory(at:includingPropertiesForKeys:options:)):
ni
Hi there!
the Swift book says:
> Extensions in Swift can:
>
> • Add computed instance properties and computed type properties
> • Define instance methods and type methods
> • Provide new initializers
> • Define subscripts
> • Define and use new nested types
> • Make an existing type conform to a
Great discussion, thanks Erika for bringing this up.
Chiming in with a little question here. The API guidelines say:
> Boolean methods and properties should read as assertions about the receiver
I know the document is about APIs but is this also recommended for local
variables and constants?
A
Sorry for the previous message. I pressed “Send” by mistake...
Here is my +1:
> * What is your evaluation of the proposal?
It’s a great improvement.
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
Definitely.
> * Does this proposal fit
05, Félix Cloutier wrote:
>
> Swift uses backticks: for `case` in cases
>
> Additionally, you can use (almost) any character inside backticks, including
> operator characters.
>
> Félix
>
>> Le 23 déc. 2015 à 18:01:20, Rudolf Adamkovič via swift-evolution
&
Ruby uses "next" keyword in place of Swift's "continue”.
I find Ruby’s word choice way better and thought it'd be worth discussing here.
P.S. Also, there is “skip”, “advance” and others.
R+
Rudolf Adamkovic
___
swift-evolution mailing list
swift-evolu
In Python, a single trailing underscore is used by convention to avoid
conflicts with language keywords:
for case in cases
...
What about Swift?
Also, it would be great to document this in Swift’s API Design Guidelines.
R+
Rudolf Adamkovic
___
swif
Zef, do you really think `rawValues` are worth adding?
With `cases`, they would be one `map` away, no?
R+
> On 23 Dec 2015, at 17:21, Zef Houssney via swift-evolution
> wrote:
>
> To be clear, I think there should be a distinction between what would be
> returned by `cases` and `rawValues`,
BTW, structures are immutable yet they can have mutating functions.
I fully understand how this works as a language user but I wonder...
Isn’t there a better keyword (than “mutating”) that we could use here?
R+
> On 23 Dec 2015, at 16:51, Ian Ynda-Hummel via swift-evolution
> wrote:
>
> I th
23 matches
Mail list logo
