I suggest we ...

Support Tabs

Don't force a code style upon users. Tabs can work perfectly well in whitespace-sensitive languages - see python or haskell - and many people prefer them.
Forcing users to use your style just comes across as petty and picky: not the impression you should be giving. Disappointing to see a promising language hamstrung by narrow-minded design decisions.

11 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

9 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Don Syme commented  ·   ·  Flag as inappropriate

    It's fair to say we're not planning to support TABs. After 8 years since F# 1.0 this is, AFAICR, the first time I've heard this suggestion, and there are lots of downvotes for it.

  • Robin Munn commented  ·   ·  Flag as inappropriate

    Stefano Pian's comment is entirely correct in that this is the one and only correct way to mix tabs and spaces -- tabs for indendation and spaces for alignment. And good editors do support this, sometimes with a little help:

    Emacs: https://www.emacswiki.org/emacs/TabsAreEvil#SmartTabs
    Vim: http://www.vim.org/scripts/script.php?script_id=231
    Resharper: https://www.jetbrains.com/help/resharper/2016.1/Reference__Options__General_Formatter_Style.html

    However, there are plenty of "dumb" editors out there that will ruin that perfect mix of tabs and spaces, and turn >---......foo (one tab plus six spaces) into >--->---..foo (two tabs plus two spaces). And that brings me to my main objection to tabs, which is that:

    **I shouldn't have to care about the whitespace in my code!**

    Mixing tabs and spaces *makes* me care about the whitespace in my code, because I usually can't trust the editor to get it right. And the time and mental energy I have to spend turning on "Show Invisibles" and peering at whitespace, to make sure that the tabs and spaces in my whitespace are being mixed correctly, is time and mental energy that I could have been spending on actual, productive improvements to my code.

    So while Stefano's suggestion is entirely correct as far as it goes, it does not change my firm belief that worrying about whitespace is unproductive. And since tab characters in code *unavoidably* leads to worrying about whitespace, I much prefer to avoid them entirely.

  • Stefano Pian commented  ·   ·  Flag as inappropriate

    I agree that the suggestion is bad, or at best an inefficient use of contributors' efforts.

    However, I want to disagree with Robin Munn's objection. There *is* one straightforward and well-known solution to the problems he presents:

    Use tabs for semantic indentation, and then if necessary add spaces for visual alignment.

    In this style, the provided example should be typed as:

    let function1 arg1 arg2 arg3 arg4 =
    >---..arg1 + arg2
    >---+ arg3 + arg4

    You can now add as many tabs as you like (if you need to change the semantic indentation of the function) and the alignment will be preserved.

  • Robin Munn commented  ·   ·  Flag as inappropriate

    If the UserVoice system allowed downvotes, I would spend 2 votes on downvoting this suggestion.

    Tabs for indentation work well when used consistently, e.g. when you will ALWAYS indent by some multiple of N (where N varies according to your preference: 4, or 2, or 8...). However, if you EVER want to line up an indented line with something on the previous line (e.g., lining up |> operators), then tabs will cause you problems. The example given at https://msdn.microsoft.com/visualfsharpdocs/conceptual/code-formatting-guidelines-%5bfsharp%5d is a simple case that would cause tab problems:

    let function1 arg1 arg2 arg3 arg4 =
    ....arg1 + arg2
    ..+ arg3 + arg4

    (Here a . represents a space). If you are coding with tabs for indentation, and use 4-space tabs (the most common setting, and IMHO the most sensible one for coding), then that would become:

    let function1 arg1 arg2 arg3 arg4 =
    >---arg1 + arg2
    ..+ arg3 + arg4

    (Here >--- represents a 4-space tab). Now the main benefit of tabs (that other coders can adjust them to their preferred indentation level) has been lost! A coder who works with 8-space tabs will see:

    let function1 arg1 arg2 arg3 arg4 =
    >-------arg1 + arg2
    ..+ arg3 + arg4

    And that doesn't line up at all.

    No. Tabs can be nice when your indentation will always be a multiple of N (whatever N may be). But because F# lets you adjust indentation by the width of an operator (plus one space), and that width may vary, tabs are unsuitable for this language.

  • TeaDrivenDev _ commented  ·   ·  Flag as inappropriate

    The language once and for all deciding that for all F# code is a *good* thing. The indentation is part of the syntax, not a question of style.

F# Language

Feedback and Knowledge Base