How about, remove branches “()” in if syntax, or make it optional to use
- You probably mean braces, not branches
- A terrible idea. Kotlin is made to be familiar for Java / C / any “curly braces” users. One does not want to break it. Also in current kotlin paradigm,
iflooks like a function with closure argument and it is very good, since it works like function with closure argument. - It obviously would tremendously complicate code parsing.
4 Likes
The parentheses in an if statement can be optional if the curly braces or another type of block delimiter are required, as in Go or Pascal. In Kotlin, the block delimiter is not required, so we need to have another type of delimiter between the condition and the expression - and the parentheses are that delimiter.
4 Likes
I have meant round brackets, sry for misunderstanding
If Kotlin is position itself like a new type lang for development it must take all of syntax sugaring from Swift.
Its not a C/Java, its a new language for comfortable development, not for storing old rudiments.
What I mean:
if someCondition && condition2 {
someStatementOrCall()
...
}
optional: (its better to always have curly braces, if hard to parse this)
if someCondition
sigleLineStatement()
Also why argument labels using ‘=’ instead of ‘:’ ?) C++ rudiment, too?
Can U pls demonstrate valid if-else statement without block delimiters, not sure where it is not required for multiline statements
Which language design law says so? Kotlin has had and has different goals than Swing. Different goals result in different syntax.
You cannot expect to be productive in a new language immediately. You must take time to learn each language. There can be a lot of concepts that are the same as those you know from languages you already know, but the syntax and semantics in each language are very likely to differ. Sometimes a bit, and sometimes a lot.
Kotlin has a lot of very nice features, and very exciting things (multi-platform and coroutines amongst others) are in the pipeline. It is up to you to decide if these features are worth the effort of getting to know Kotlin.
For multi-line blocks the braces are always required, but it is undesirable to require them for single-statement/single-expression blocks. Compare these two statements:
val x = if (someCondition) { 3 } else { 4 }
val x = if (someCondition) 3 else 4
2 Likes
Ok, than, why we need a round brackets if we have block delimeter?
The law about more sugar = more users. Now we watching a big migrate from Java to Kotlin only cause of syntax sugar. Yes, I have coded in old vanilla C too, but if U make a new PL, U need to be guided by another new PLs, to run a good market competition. Btw, PL main aim must be is to keep balance in readability/brevity, i.e. cut off unneeded things, even if it will have a harder processing.
Because you can leave of the braces if you only have 1 statement/expression, and if you don’t use parentheses in this case, the parser will become a lot more complex and slower. Try building a toy parser yourself that supports your proposed syntax.
You keep saying this without anything to back this up. Why do all new programming languages have to look alike? Given language design history, it is very unlikely there is one true design that is clearly better than others. And how can you objectively measure readability? I think LISP-like code is horrible, but other people find it readable.
Kotlin already has reduced the number of unneeded things. In my experience the amount of needed code is about 50% of that of Java. And building reasonably simple Kotlin projects already takes too much time in my opinion, so a syntax that makes compilation take even longer is undesirable for me.
That subj was being already discussed here https://discuss.kotlinlang.org/t/feature-request-removing-unnecessary-parenthesis/1607
yeah, its better to save ternary operator istead of keeping round brackets
will be cool to make a voting for this feature, but I think its unreal
very imho: jetbrains must fire them senior language designer (hello from literal container initializers, and other shit design))
gl hf
If you cannot stand Kotlin, why not switch to a language you do love? There are many to choose from. Why do you insist on using Kotlin, but then demand that it must be changed to a completely different language?
2 Likes
= instead of : in argument, as in Kotlin, : is used to declare data types, so having : again for arguments will confuse developers.
My coworker just commented that the number of users who rejected Kotlin because it requires braces around the condition of an if, is probably exactly 1.
8 Likes
Please keep the discussion constructive. If you have specific feedback on specific design decisions, you’re welcome to share it, but if you find Kotlin’s design to be unsatisfactory in general, please use a different language. There’s plenty to choose from.
8 Likes
val x = if boolean somevalue else someothervalue looks horrible and is hard to read.
1 Like
I can comment here once moar, that swift have better design in this question
use if instead of ternary operator allowed this brackets hollywar to be,
even this looks better
val x = if bolean ? somevalue else someottherParentheses lead to clarification of syntax necessary in order to do Kotlin lambda parameters/builders. Assuming that higherOrderFunction(function) returns a boolean, this clarifies the intent clearly.
if (higherOrderFunction { doSomething() }) 3 else 2
On the other hand, this is extremely ambiguous.
if higherOrderFunction { doSomething() } 3 else 2
4 Likes
There is no reason to complicate the frontend of the compiler, make it harder to maintain, and harder to understand, just because you think round brackets look ugly.
U don’t understand language design, its not about compiler frontend complexity, its about brevity of language creating, if we care about complexity, people must be programing on C now, and not on Ruby/Rust/JS/Swift/etc
You missed my point. It makes the compiler more complex and provides no tangible benefits to the programmer.
2 Likes