> 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
