When I first saw data classes I was a bit confused about the keyword data. Afterwards I've learned that it is a simple annotation. Now I consider whether it would be better to make the square brackets mandatory in all cases. Plus you don't have to explain when they are mandatory and when not. Syntax variance is not the best thing in the world.
Christian
Wouldn't that just be extra noise?
Yes, in principle it would be extra noise, but you'd win more clarity. I would vote to abstain from square brackets around annotations, if it would always be possible leave them out.
I was experimenting with data classes as nested classes and got a compiler error, because I left out the square brackets. It wasn’t obvious to me that “data” is an annotation and that I need to surround it with square brackets in certain cases. My opinion is that this potential confusion is not justified by a slightly nicer syntax.
Could you please provide an example where nested class with data annotation produced a compiler error?
+1
See an other thread of mine: http://devnet.jetbrains.com/thread/456240
I see, thanks, you mean "local" classes, not "nested" classes :)
I thought it was a keyword!
I just saw one more reason to make square brackets mandatory:
platform(static, name(“foo”)) // this is an annotation
fun bar() = …
platorm(…) looks like a method call and not like an annotation. Very confusing.
That got me confused as well, when I saw the platform static discussion. At first sight, I thought they were method calls as well. But I guess in the IDE you have better syntax highlighting than here in the forum. I don't like the idea that there are annotations with square brackets and others without them. On the other hand I do see the value of data class over [data] class, especially as square brackets can't be typed comfortably on a German keyboard.
I worked quite a lot with Groovy compiler transformations on a project. Are there any plans to provide something like that for Kotlin as well? If there are: being able to create annotations that feel as much as possible like syntax would be a desirable goal (thus, annotations without brackets whereever possible). If there aren’t, I wouldn’t even care if data was an annotation or just part of the syntax (thus, all annotations should have brackets for consisency reasons and data probably shouldn’t be an annotation).
Just to be curious: why is it so much more difficult to parse annotations without square brackets for local classes than in other contexts?
It seems that I am not the only one who don't like annotions that can be written with and without square brackets. Dirk, you're absolutely right, that [ and ] is hard to type on some keyboards. Personally I prefer @Annotation(param = "x") over [Annotation(param = "x")]. Parenthesis and square brackets at the end don't look good.
So, why not simply follow the Java and Scala way and use @ instead of square brackets and make it mandatory?
medium wrote:
It seems that I am not the only one who don’t like annotions that can be written with and without square brackets. Dirk, you’re absolutely right, that [ and ] is hard to type on some keyboards. Personally I prefer @Annotation(param = “x”) over [Annotation(param = “x”)]. Parenthesis and square brackets at the end don’t look good.
So, why not simply follow the Java and Scala way and use @ instead of square brackets and make it mandatory?
+1 I actually don’t care about brackets vs. at-sign (as I abandoned non English keyboards years ago), but I do care about uniformity. Writing always whatever makes it easy for newbies, being able to leave it out nearly always means that they will get lost once they have to annotate something in a local scope. Additionally, it being optional makes a new tiny style flame war possible.
In this regard I like the Go approach to limit syntax variance. Go even forces you to write curly braces around single statement if's, and it forces you to do it in 1TBS style and nothing else. This is an extreme approach, but it makes Go code pretty uniform and good to read.
I can see debates about annotation style in Kotlin coming, if there is more then one way to write anntotations.
In this regard I like the Go approach to limit syntax variance. Go even forces you to write curly braces around single statement if's, and it forces you to do it in 1TBS style and nothing else.
I'd do it the other way: Forbid braces around single statements. But I'm afraid I'm the only one. ;)
+1 for enforcing 1TBS.
I’d also forbid class names starting with lowercase, etc.
I can see debates about annotation style in Kotlin coming, if there is more then one way to write anntotations.
Do we want to start flaming just now? 
FWIW I try to avoid curly braces around single line if statements unless there's an else block that'd require them to be visually balanced.
The rationale is that vertical screen space is a valuable asset. I try to avoid too many superfluous blank lines for this reason too. Though it’s a balance.
Test fun foo() reads so nice. Without brackets even more fun than with brackets.
I can understand this point of view, since I'm not a fan of wasted screen space, too. But curly braces around if blocks help to avoid mistakes. Have you heard of Apples goto fail bug?
I can understand this point of view, since I'm not a fan of wasted screen space, too. But curly braces around if blocks help to avoid mistakes. Have you heard of Apples goto fail bug?
Sure I have. But to be precise: I always format like this
if (something) doSomething();
If there are more statements or the whole doesn’t fit in line, I use the 1TBC style. I’ve made tons of mistakes, but no single one was caused by such oneliners. The risky thing is
if (something) doSomething(); foooo(); // GOTO FAIL :D
and even this is really risky only if the IDE doesn’t format it on the fly. I guess the safest thing would be to drop braces altogether and depend on indentation. 
I have indeed heard of goto fail! But I agree with Martin, when using an IDE that properly indents code automatically this sort of mistake is very hard to miss, especially as "if ladders" like Apple's are a typical sign of C (or maybe Go) code. When I look back over the past five years of coding and think about all the bugs I've written, I can't remember any that would have been prevented through a religious use of brackets style.
JetBrains Folks,
what do you think about mandatory square brackets (or @Annotation) for annotations after this discussion? I think this discussion has shown pretty good reasons to change the current syntax. Especially annotations with parameters are looking like method calls without square brackets.