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
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    9 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      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