Straightforward question - Are typealiases within protocols supposed to be
visible from conforming types?
For example:
> protocol MyProto {
>
> typealias ComplexFunctionType = (_ paramOne: (Int, Bool?), _ paramTwo:
> (Bool, String?, String)) throws -> (Array, Float)?
>
> fun
> On Aug 3, 2016, at 3:36 PM, Jon Shier wrote:
>
> If you think Date and Data look similar at a glance, wouldn’t NSDate and
> NSData? Or are you comparing this against your old Array type?
Fair question. I did think of that. I did actually port this code from
Objective C. For whatever reason,
If you think Date and Data look similar at a glance, wouldn’t NSDate and
NSData? Or are you comparing this against your old Array type?
> On Aug 3, 2016, at 6:33 PM, Travis Griggs via swift-users
> wrote:
>
> I realize this ship has probably sailed a long while ago. I really like the
> way th
I realize this ship has probably sailed a long while ago. I really like the way
the Foundation library is shaping up. With the changes in Swift3, I’ve been
moving any of my Array cases to using Data. A handful of handy
extensions to Data have made working with it nice. It’s much easier to figure
On Wed, Aug 3, 2016 at 3:51 AM, Rick Mann via swift-users <
swift-users@swift.org> wrote:
>
> > On Aug 2, 2016, at 19:06 , Jordan Rose wrote:
> >
> > I don’t think it makes sense to do this. A protocol cannot control how a
> particular property is implemented (stored or computed), and any conform
> On Aug 2, 2016, at 19:06 , Jordan Rose wrote:
>
> I don’t think it makes sense to do this. A protocol cannot control how a
> particular property is implemented (stored or computed), and any conforming
> type must initialize all of its stored properties before returning from its
> own initia
> Protocols currently require you to redeclare their properties, but we could
> add a feature to change that if there was a strong enough justification.
Sometimes, this would be very handy (not only for structs) — but I'd expect
that there are at least as many cases where you don't want that beh
