Re: [swift-dev] switches versus the visitor pattern?

> On Aug 12, 2017, at 6:45 AM, David Zarzycki wrote: >> On Aug 11, 2017, at 19:21, John McCall wrote: >> >>> On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev >>> wrote: >>> Hi Slava, >>> >>> Thanks. I’m not planning on

Re: [swift-dev] switches versus the visitor pattern?

> On Aug 11, 2017, at 19:21, John McCall wrote: > >> On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev >> wrote: >> Hi Slava, >> >> Thanks. I’m not planning on seeking them out. I just want to minimize future >> merge conflicts with an

Re: [swift-dev] switches versus the visitor pattern?

> On Aug 11, 2017, at 7:05 PM, David Zarzycki via swift-dev > wrote: > Hi Slava, > > Thanks. I’m not planning on seeking them out. I just want to minimize future > merge conflicts with an experimental branch I’m working on. The visitor > pattern helps people like me by

Re: [swift-dev] switches versus the visitor pattern?

Hi Slava, Thanks. I’m not planning on seeking them out. I just want to minimize future merge conflicts with an experimental branch I’m working on. The visitor pattern helps people like me by minimizing the number of boilerplate updates a person needs to do after adding a new type to the type

Re: [swift-dev] switches versus the visitor pattern?

I’ve seen some switches over TypeKind more easily expressed as a series of if/else if statements also. However unless you come across an ugly switch that you want to refactor while working on something else, I probably wouldn’t spend time actively seeking them out and changing them. I don’t

[swift-dev] switches versus the visitor pattern?

Hello, Before I spend time creating patches, are there arguments against converting exhaustive switch statements to the visitor pattern in the Swift source base? In particular, I’m curious about switches that reason about the TypeKind enum. Thanks, – Dave