Open Happypig375 opened 5 years ago
The style guide suggests "place the attribute on its own line" (for [<Literal>]
s but this naturally extends to other attributes). Consistency is good here.
@charlesroddie although the style guide does mention that, at the end of the day it's only style. I think having consistency in the language is key here; we want people to adopt that guide not because they have to, but because they agree with its contents.
Allowing attributes on module declarations would be a good addition, marking as approved.
Just to add, you can already place the attribute on the same line as module
: in front of it, like so:
[<AutoOpen>] module M =...
However, the indentation rules are iffy when it comes to prepending with attributes, sometimes the attribute is counted, sometimes it is not, as can be seen in this example:
[<AutoOpen>]
module M =
[<AbstractClass>] type C() = class end
[<AbstractClass>] type D() = class end // no indentation warning
[<AbstractClass>] type E() = class end // no indentation warning
[<Literal>] let X = 3
[<Literal>] let Y = 3 // indentation warning
[<Literal>] let Z = 3 // indentation warning
In the case of module
, the indentation rules consider the position after the attribute(s), which in turn would mean everything needs to be indented to the right. Not an ideal workaround ;).
Related: https://github.com/fsharp/fslang-suggestions/issues/514
I know I'm late here, but...
This is not only good for style, but also safety. I have mentioned this elsewhere, but it bears repeating. When attributes are placed above the code they affect, there is a risk that code creep will introduce unintended changes that go unnoticed. The possibility to place attributes inside the code elements they affect, will considerably reduce the risk of code creep.
Code creep is the term used to describe what can happen with source code when attributes, directives, pragmas - whatever they're called in your favorite language - are used. While editing, it is far too easy to overlook the relationship between these kinds of source elements and the structured code that they affect, resulting in cut and paste of code snippets without their attributes. The code may still compile, with the attributes now affecting the wrong elements.
Niklaus Wirth banned these kinds of elements from his programming language Oberon. We can't do that in F#, but I think it would have been nice to have optional warnings for attributes placed before code elements rather than inside. Just an idea.
RFC https://github.com/fsharp/fslang-design/blob/main/preview/FS-1107-Allow-attributes-after-the-module-keyword.md
Allow attributes after the module keyword
Consider:
The
Literal
attribute can be embedded into thelet
:Same for the
AbstractClass
:But not the
AutoOpen
.The existing way of approaching this problem in F# is leaving the
AutoOpen
above themodule
.Pros and Cons
The advantages of making this adjustment to F# are
module
s are just specializedtype
s, so placing attributes after the keyword should be allowed as well.The disadvantage of making this adjustment to F# is having more ways to do the same thing. However, precedence has been already made for
type
s andlet
s.Extra information
Estimated cost (XS, S, M, L, XL, XXL): S
Related suggestions:
33
I would say that this should be allowed for
member
s as well.Sure, what we have works, but inconsistent language features are worse than having multiple ways to do the same thing. (Recall: Unification of List, Array, Seq functions in F# 4.0)
Whether the lines become long depends on the length of the name of members and attributes. If they are short enough, they deserve to be combined to utilize more horizontal space.
Affidavit (please submit!)
Please tick this by placing a cross in the box:
Please tick all that apply: