Amir's idea is interesting to me.
But I like Xiadi's solution with unused closure, and I don't see a reason to
put more effort into this.
It works well with simple and complex cases, and anyhow, for complex cases,
feature switches and/or branches are already suitable, like said before.
Pierre
> Le 16 janv. 2017 à 06:39, Step Christopher via swift-evolution
> <swift-evolution@swift.org> a écrit :
>
> These (maintaining a clean codebase, using source control, branching) are
> good practices for solo developers as much as anyone else.
>
>> El ene. 15, 2017, a las 2:24 PM, Amir Michail via swift-evolution
>> <swift-evolution@swift.org> escribió:
>>
>>
>>> On Jan 14, 2017, at 8:11 PM, Jay Abbott <j...@abbott.me.uk> wrote:
>>>
>>> I think this would be an anti-feature , here are some reasons why:
>>>
>>> • If it is code you wrote as an idea for how something might be
>>> implemented in the future, then it should be manually tweaked/validated
>>> anyway when you put it back in. If things change slightly such that your
>>> old commented code breaks when you comment it back in this is a good thing,
>>> it forces you to check/amend the old code so that it functions properly in
>>> the updated environment that it now inhabits.
>>> • If it’s a significant amount of code then it really ought to be
>>> structured into something appropriate, like a function or a class, in which
>>> case it can happily live uncalled and not commented out. But it’s not a
>>> great practice to leave unused code lying around, unless you know it’s
>>> going to be used soon.
>>> • Commented code is often commented out specifically to make things
>>> compile while you tweak/break things somewhere else (i.e. commented out
>>> temporarily) - so of course you don’t want it to be compiled.
>>> • If you comment out code temporarily then it really should just mean
>>> temporarily, i.e. between now and your next commit to test something
>>> immediately. Source control means there’s no need for longer-lived
>>> commented out code. Unfinished code can live on a branch, old code that you
>>> might want to refer to or re-use later is in your source control history,
>>> and unused code should probably just be removed.
>>
>> Other developers may prefer to have some code comments. Solo indie
>> developers have more freedom to just do what they want in this respect...
>>
>>> • Code that is written and working and intended to be enabled later on
>>> should be activated by a feature-toggle (either a compile-time or a
>>> run-time one) rather than commented out.
>>>
>>>> On Sun, 15 Jan 2017 at 00:04 Amir Michail via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>> On Jan 14, 2017, at 6:56 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>> On Sat, Jan 14, 2017 at 5:50 PM, Amir Michail <a.mich...@me.com> wrote:
>>>>>
>>>>> On Jan 14, 2017, at 6:46 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>>
>>>>>> On Sat, Jan 14, 2017 at 5:35 PM, Amir Michail <a.mich...@me.com> wrote:
>>>>>>
>>>>>> On Jan 14, 2017, at 6:28 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>>>
>>>>>> This has been brought up on this list before. The conclusion of the
>>>>>> previous thread on this topic was that there is a way to do this:
>>>>>>
>>>>>> #if false
>>>>>> // put your code here
>>>>>> #endif
>>>>>>
>>>>>
>>>>> This would not check the code for compilability within the surrounding
>>>>> code. This requires more than a syntax check.
>>>>>
>>>>> I can't say I've ever needed that feature; could you share a concrete use
>>>>> case?
>>>>>
>>>>
>>>> Consider an array of levels for a game where some levels are commented out
>>>> for possible future use. It would be nice to have such level entries
>>>> continue to compile as the code elsewhere evolves and yet not be included
>>>> in the executable.
>>>>
>>>> ```
>>>> enum Levels: Int {
>>>> case foo = 1, bar, baz, boo
>>>> }
>>>>
>>>> var levels: [Levels] = [
>>>> .foo,
>>>> .bar,
>>>> ]
>>>>
>>>> // disabled
>>>> _ = {
>>>> levels += [
>>>> .baz,
>>>> .boo,
>>>> // this won't compile if you add:
>>>> // .nonExistent,
>>>> ]
>>>> }
>>>> ```
>>>
>>> That’s helpful thanks! I still think code comments would be nice though.
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
