on Sat Feb 04 2017, Saagar Jha wrote:
> Sorry, it looks like I left you hanging on this–luckily I found it when I was
> cleaning my inbox.
>
> Overall, I believe the issue I have with the Swift String indexing
> model is that indices cannot be operated on like an Int can–you can
> multiply, div
on Fri Feb 03 2017, Ben Cohen wrote:
>> On Feb 3, 2017, at 3:27 PM, Dave Abrahams via swift-evolution
>> wrote:
>>
>> I don't always make zip a method, but when I do, its argument label is
>> “to:”
>
> Hmm, that doesn’t sound very natural to me.
>
> Then again the problem with “zip(with:)" is
on Sat Feb 04 2017, Jonathan Hull wrote:
>> On Feb 2, 2017, at 2:19 PM, Dave Abrahams wrote:
>>
>>
>> on Thu Feb 02 2017, Jonathan Hull wrote:
>>
>>> Just out of curiosity, what are the use-cases for an infinite sequence
>>> (as opposed to a sequence which is bounded to the type’s represent
I'm coming around to the idea of discourse, mainly because that would allow
providing a consistent display of the discussion and not having every
subscriber reinvent the way he wants to see threaded discussion, quotations
and code samples. As discourse supports mailing list mode, which would
allow
I agree with you on point number two. There is way too much scrolling. Im
viewing it on mobile so that's even more scrolling. Discourse allows
jumping to the next topic so if I don't want to scroll I can jump to the
next topic.
On Sat, Feb 4, 2017 at 2:36 PM Cihat Gündüz via swift-evolution <
swift
After trying out Nate Cook’s Discourse test server I’d like to add a few things
on my previous message:
#1 I found the beginning of this threads discussion without any problems (both
from navigating through the threads structure and from the search feature)
which was interesting for me, as I co
Apologies for re-posting this, but I got some message undelivered e-mails for
it so I'm not 100% sure if it went through the first time or not:
> On 31 Jan 2017, at 09:07, Alex Hoppen via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
>
> This was a deliberate change between Swift
No, but you can declare it as:
lazy var myStateDerivedProperty: Int = self.myStateManager.property
Of course, there are still more complex scenarious that require IUOs. For
example anything that gets loaded from the UI (currently marked as @IBOutlet).
IUOs are definitely useful for items that w
Dependency Injection does sort out this case, you're right.
One case it doesn't fix is where your initialised value depends on something
within your superclass to be created first to derive your initialising value.
class MyBaseClass {
let myStateManager: StateManager
init() {
//
> Le 4 févr. 2017 à 16:52, Rod Brown via swift-evolution
> a écrit :
>
> Hi Joe,
>
> I think this comes back to the idea that a lot of people in the wider Swift
> community hold that Implicitly Unwrapped Optionals are “bad” and
> “discouraged", and therefore shouldn’t be used. There seems to
It’s clear that a lot of work has gone into identifying and evaluating several
different approaches. Thank you for doing the hard work here!
I think I might have one additional alternative to consider. I like the idea
of using Package.swift to specify the tools version, but I think the
disadv
Hi Joe,
I think this comes back to the idea that a lot of people in the wider Swift
community hold that Implicitly Unwrapped Optionals are “bad” and “discouraged",
and therefore shouldn’t be used. There seems to have been much pushback on
Implicitly Unwrapped Optionals in the Swift 3 timeframe,
> On 26 Jan 2017, at 18:02, Nate Cook wrote:
>
>> On Jan 25, 2017, at 3:32 PM, Douglas Gregor wrote:
>>
>> I’ve looked into Discourse a bit, and it does look very promising. One
>> *specific* way in which a motivated individual could help would be to take a
>> look at Discourse’s import script
I like this solution much better than the prior alternative.
When a protocol member is removed or renamed, marking it as deprecated is
the proper and natural thing to do. And when a conforming type implements a
deprecated requirement, there ought to be a warning.
This is vastly superior to the id
I am currently working on updating some protocol APIs in a framework that's
shared among several of my projects. The issue here is that the protocol has an
extension with default implementation. For example:
protocol Foo {
func doSomethingWithArray(_ arr: [String])
}
extension Foo {
fun
This inconsistency could be solved by giving optionals a method to specifically
perform side effects.
In the same way that arrays have a 'map' function for retuning new arrays and a
'forEach' to return '()' and perform a side effects. Option could have a
'forEach' method that returns '()'.
s.
Sorry, it looks like I left you hanging on this–luckily I found it when I was
cleaning my inbox.
Overall, I believe the issue I have with the Swift String indexing model is
that indices cannot be operated on like an Int can–you can multiply, divide,
square, whatever you want on integer indices,
> On Feb 2, 2017, at 2:19 PM, Dave Abrahams wrote:
>
>
> on Thu Feb 02 2017, Jonathan Hull wrote:
>
>> Just out of curiosity, what are the use-cases for an infinite sequence
>> (as opposed to a sequence which is bounded to the type’s representable
>> values)?
>
> 1. The type may not have an
18 matches
Mail list logo
