variable definition

[benilaunchers]

hello i hope you well.
in this version and syntax of carbon we declare variables like this. imagine we want to create integer var temp: i32 = 5; or use auto after :.
i think this : and type after colon is redundant. in my opinion it's better to do this.
for integer variable var32 temp = 5; or vari32 temp = 5; or for auto variable we dont need to write it like var temp = "hello world!".
i think it's better to read, write and learn without a little time redundant.

[DevNoteHQ]

And how would you do class-types then? Lets say you have a Class Cat. Then just the C++ syntax Cat temp = {}? Or would you construct a keyword for it varCat temp = {}?
The reason behind the use of var is the much easier parseablility and thus faster compilation time and also better readability. So the first one is not really an option.
I don't know why you would necessarily write them together though? That just complicates things. Why not var Cat temp = {}^^
I think that was one suggestion, but was not accepted since var temp: Cat = {} is just more readable. The colon makes it very easy to identify the Type of the variable^^

[benilaunchers]

ok im with you. i undrestood.
but why not using const instead of let?

[DevNoteHQ]

That's still kind of up for discussion. let was prefered so far because it also has three letters and because it's more a keyword for a mathematical definition. It fits better for the planned syntax with patterns:

let (a: i32, var b: i32, c: i32) = (1,1,1);

Where a and c are constants and b is a variable. Though i suggested using something like ~: instead to mark an entry to be deviating from the main keyword. So the given example would translate to:

let (a: i32, b~: i32, c: i32) = (1,1,1);

The same could then be done with var:

var (a: i32, b~: i32, c: i32) = (1,1,1);

Where b is now a constant and the others are variables. Then it would also be legitimate to use const instead of let. Though I would advocate for val aka value instead since this sticks to 3 letter keywords.

[sirlordt]

This syntax is really bad idea. When i read to let keyword i assume all are constants. I too lazy to search the var in the expression. You can easy introduce bugs. If are const all expression must be const. If are var all expresion must be variables.

[DevNoteHQ]

How else would you do this destruction syntax with mixed constants/variables?
Bugs are not really possible. The compiler will tell you if you try to reassign a constant.

[flysand7]

I agree that : auto is redundant, since there is already some version of type deduction. This is something that was already discussed in the Carbon community and the reason we don't add it is because saying nothing to deduce types is over-encourangement of using type deduction, which may make the code hard to read, since you have to traverse chains of auto declarations to find out where the type of the variable is specified the first time.

I will quote Kate Gregory's message on discord:

A good use of auto is one where there's no need to think hard or reason out types. So in C++ if I write Employee* nextEmployee = getNextEmployeeToProcess(); making that auto instead is unlikely to bother a reader. Same for (for auto const& emp : EmployeesToProcess) - you know what emp is there and don't need to reason it through or hover over anything. But auto by default or auto if you don't say anything not only over-encourages auto, it confuses new readers. Why are types sometimes mentioned and sometimes not? Suddenly you're teaching the type deduction rules (otherwise the newcomers just want to leave them off all the time and never mention them) and other things that I would rather wait to teach.

Second point, about using vari32 instead of var ...: i32, I don't think you're reducing that redundancy since in both cases you specify:

• Keyword for declaration
• Name of a variable
• Type of a variable

You're not reducing the redundancy, but you're making the syntax a bit more complicated by adding new keywords. It doesn't seem like simply reducing the number of characters is worth the tradeoff in complexity of the syntax.

[JamesJCode]

Which probably means that auto functions are commonly recognized as bad practice and thus are not really used often? If that's the case then why have this feature anyway?

Just building on @geoffromer's reply - you don't always know the type that a function is returning but the compiler does, and that's really where the power of auto return types comes in. This is most often seen where a function is returning something where the concrete type isn't known, like a lambda function (although we're looking at some interesting 'boxing' options to allow concrete lambda interfaces to be returned, albeit likely with some overhead), or in generic code where the return type depends on the generic / templated parameters. Outside of those kinds of use-cases, it's down to personal / project / corporate style how much auto return types are or aren't used.

[DevNoteHQ]

My interpretation is that (at least in the codebase I'm familiar with) people rarely use auto return types, and are reasonably careful to make sure that the actual return type is clear without further indirections, and/or doesn't matter. Just because it's rarely used doesn't mean using it is a bad practice, it just means that the use cases where it adds value are relatively rare.

@geoffromer Fair enough. But that's still something that you have to teach a newcommer. Otherwise I'm pretty sure that people tend to overuse auto for convenience. And thus will also overuse auto for variables, which was the starting point for this discussion^^

var (x, y) := foo();

@mossaiby And what about var (x: auto, y: i32) = foo();? Where x might be a super long Class like TenderProcurementArticleSupplierBidding, so auto is more convenient but y is not clear from the function name and thus the fixed type? := doesn't really solve the problem with over usage of deduced types. So I would argue that if we could solve or at least minimize the over usage problem, then just omitting the type including the colon is easier and already tested and in use in Kotlin/Rust/TypeScript, which are probably the most influential languages for Carbon.

Just building on @geoffromer's reply - you don't always know the type that a function is returning but the compiler does, and that's really where the power of auto return types comes in. This is most often seen where a function is returning something where the concrete type isn't known, like a lambda function (although we're looking at some interesting 'boxing' options to allow concrete lambda interfaces to be returned, albeit likely with some overhead), or in generic code where the return type depends on the generic / templated parameters. Outside of those kinds of use-cases, it's down to personal / project / corporate style how much auto return types are or aren't used.

@JamesJCode Lambda functions are just syntactic sugar for "inline" functions (not the keyword inline) to make something like map easier. So the same complexity in deducing the return type of a normal function applies to a lambda function. For example, this is how Kotlin declears the map function using extension functions:

inline fun <T, R> Array<out T>.map(
    transform: (T) -> R
): List<R>

Which can then be used to write something like:

val listOfPairs = listOf(Pair(2,5), Pair(10, 8));
val firstValues = listOfPairs.map { it.first }; // In Java this would be .map(it -> it.first)

Since Kotlin doesn't support auto return types and makes heavy use of lambda expressions, I kind of doubt that auto return types are really necessary for lambdas. Same goes for Rust and it's map function. And if I'm not mistaken, the same should be possible in Carbon with it's generics system.
I could imagine that it would become tedious to specify tuple and struct return types with multiple fields, but in such a case I would argue that creating a DTO for it instead of using a auto return type is much better for readability and maintainability of the code.

[JamesJCode]

@JamesJCode Lambda functions are just synthetic sugar for "inline" functions (not the keyword inline) to make something like map easier. So the same complexity in deducing the return type of a normal function applies to a lambda function.

They're not just an inline function when they have an associated closure as they have some (sometimes mutable) state they need to carry around with them too. They start to look a lot like anonymously-typed classes which implement some kind of callable operator, at least in a C++-like model. I don't know how Kotlin handles closures and lambda typing though.

That aside, the generics argument still remains.

[mossaiby]

@DevNoteHQ I just suggested a less verbose syntax for auto variables; I know that it doesn't solve other problems. Anyway, about your example, I think there is no way to use := operator in my suggested syntax, as far as I can tell. But, if I was writing that piece of code, would it make sense to specify the type of one of the variables, and use auto for the other one? Even in C++ the syntax doesn't allow that (I am not 100% sure, though).

[DevNoteHQ]

They're not just an inline function when they have an associated closure as they have some (sometimes mutable) state they need to carry around with them too. They start to look a lot like anonymously-typed classes which implement some kind of callable operator, at least in a C++-like model. I don't know how Kotlin handles closures and lambda typing though.

Again, syntactic sugar. The closure just allows the lambda to access data in the stack, similar to a function parameter. This is just an extension to function parameters since a function like map only accepts a lambda with one argument, which is the element within the list/array that should be mapped.

That aside, the generics argument still remains.

Well I'm not deep into generics and don't know exactly what you mean but I would argue that if the compiler is able to deduce the type, then the user should also be able to state the type? Also Kotlin and Rust have done generics without auto return types and I doubt that Carbon will do something so revolutionary new that it can't be done without a auto return type (and without a lot of extra code).

@DevNoteHQ I just suggested a less verbose syntax for auto variables; I know that it doesn't solve other problems. Anyway, about your example, I think there is no way to use := operator in my suggested syntax, as far as I can tell. But, if I was writing that piece of code, would it make sense to specify the type of one of the variables, and use auto for the other one? Even in C++ the syntax doesn't allow that (I am not 100% sure, though).

Doesn't seem like it. C++ seems to only allow auto for structured bindings. That was just an example how I think mixing fixed and deduced types could be used in practice. I remember using something like that in Kotlin once or twice.