Yes.
But: Only if it makes the code better.
I think that “understandability engineering” is just as important as “software
engineering”. Maybe more so. After all, code that we understand has a better
chance of working correctly than code that follows all paradigms but once the
developer is gon
Huh, I didn't realize you could nest functions like that. That being said, I'm
not sure the declare-then-use structure really appeals to me personally. I
might use it if the function was getting really long.
One last question: labels on do blocks. I know they are mostly intended to be
used for
> On 20. Jun 2017, at 01:38, Muhammad Tahir Vali via swift-users
> wrote:
>
> Hey all,
>
> I wanted to know if theres a work around for a problem I am having
>
> lets say I have a protocol
>
> protocol Graphable : CustomStringConvertible, Sequence, Collection {
> var vertices : [AnyVert
@David But the automatic conformance is currently supported through
extension A where Self: B.
@Slava When does extension A where Self: B not equal extension B where Self:
A? Why would protocol inheritance not be communicative?
On June 19, 2017 at 5:26:44 PM, David Sweeris (daveswee...@mac.com)
IIUC (which shouldn't be assumed on your part) the difference is that any types
which conform to both `A` and `B` will automatically conform to `CProtocol` as
well, but not `C`. I suspect the "automatic conformance" bit is why we don't
currently allow it.
- Dave Sweeris
> On Jun 19, 2017, at 1
Hey all,
I wanted to know if theres a work around for a problem I am having
lets say I have a protocol
protocol *Graphable* : CustomStringConvertible, Sequence, Collection {
var vertices : [AnyVertexable] { get set }
*var edges: [AnyEdge]? { get set }*
}
Then I have 2
> On Jun 19, 2017, at 11:47 AM, Michael Savich wrote:
>
> Yeah, it's all about balance to be sure. Though one benefit of do blocks is
> in functions that are tied to a sense of time. It seems to me that the in
> case of something like viewDidLoad separating code into too many functions
> can
What I usually do here is:
typealias CProtocol = A & B
protocol C: CProtocol { } // or just A & B directly, I think
extension C {}
So it’s a bit silly to me.
Jon
> On Jun 19, 2017, at 3:44 PM, Slava Pestov via swift-users
> wrote:
>
> Hi Steven,
>
>> On Jun 19, 2017, at 11:44 AM, Steven Br
Hi Steven,
> On Jun 19, 2017, at 11:44 AM, Steven Brunwasser via swift-users
> wrote:
>
> Is this error intentional, or a bug?
It’s intentional. We could add support for this as an extra bit of sugar, but
note that
> Since extension A where Self: B is the same as extension B where Self: A,
Yeah, it's all about balance to be sure. Though one benefit of do blocks is in
functions that are tied to a sense of time. It seems to me that the in case of
something like viewDidLoad separating code into too many functions can obscure
the fact that the code is meant to be executed at that time
Is this error intentional, or a bug?
protocol A {}
protocol B {}
typealias C = A & B // valid
extension C {} // Error: Non-nominal type 'C' (aka 'A & B') cannot be
extended
extension A where Self: B {} // valid
struct Foo: C {} // valid
Since extension A where Self: B is the same as e
Introducing scope to manage lifetimes of local variables is a useful and
valuable practice. Note that it might also be an opportunity to refactor the
code. Any do block you want to introduce could also be a local function
definition that you call later. Alternatively, it could be generalized and
> On 19. Jun 2017, at 04:30, Nevin Brackett-Rozinsky via swift-users
> wrote:
>
> Is there a way to restrict the associated values of an enum? For example,
> suppose I have this type:
>
> enum Angle {
> case radians(Double)
> case degrees(Double)
> }
>
> I want to ensure that the rad
> On 19. Jun 2017, at 20:03, Karl Wagner wrote:
>
>
>> On 19. Jun 2017, at 04:30, Nevin Brackett-Rozinsky via swift-users
>> mailto:swift-users@swift.org>> wrote:
>>
>> Is there a way to restrict the associated values of an enum? For example,
>> suppose I have this type:
>>
>> enum Angle {
Hi Swift-Users,
I was wondering if there is any way to decode JSON from Any type JSON
Object using `JSONDecoder`, not from Data type object.
Currently, `JSONDecoder` has only one decode function which decodes Data
type object to `Decodable`. Inside the function, it serializes Data object
to Any T
So, something I did not know until recently is that do blocks in Swift are for
more than just error handling, they can also be used to tighten scope.
I'm wondering, why not use a ton of do blocks? Like, if I have a ViewController
lifecycle method like viewDidLoad, I could segment it into out a
> On Jun 18, 2017, at 10:33 PM, Howard Lovatt via swift-users
> wrote:
>
> To me Angle is a unit with two common representations: radians and degrees.
> It's not an enum because it doesn't have two values, it has one value that
> you can view in two ways.
>
> Therefore I would make an Angle
17 matches
Mail list logo