Comments (12)
x = 123
is ambiguous: does this declare or only assign to x?
from odin.
PHP is $x = 42;
, not x := 42
, so this was a rather stupid comment to begin with.
from odin.
You're welcome to join us in Discord to discuss this further. This issue is closed.
from odin.
Writing the actual language itself, if one still decided so, it will be harder to see in the code where variables are declared vs assigned because it's so easy to skip this little
:
in the code
I can actually relate to this. Had a few shadowing bugs happen because I wasn't looking when copying declarations over to assignments.
bit of deal-breaker to me
I guess it's mostly the question about your values, because it's really such a small issue that doesn't get in your way that much when programming.
Though it would probably annoy you every day if you went with learning Odin, the same way a lot of Odin's syntax choices annoyed me the first few months I was using it. I still don't totally like them, but I've learned to cope. Programming languages are made to solve practical problems, not satisfy aesthetics.
If you are hoping that there will be a change in the way our declaration syntax works, I'd have to disappoint you, it's probably not going to happen. But I do recognize that var
/let
would be a better choice for declaration syntax aesthetically and practically.
from odin.
https://odin-lang.org/docs/faq/#what-does--mean
What does :=
mean?
This is two different operators :
and =
; is used for variable declarations. The following are all equivalent:
x : int = 123
x : = 123
x := 123
x := int(123)
Warning: If you post a comment like this again, and also 👍 your own comment, you will be banned. This is effectively just spam.
from odin.
So basically it’s just a skip for type inference, but if I tell the type explicitly, then I can use normal =
, – that’s good.
Ok, that makes a little more sense. Though I still don’t see why would you need :=
exactly.
Can’t compiler just automatically see if there’s an explicit type, or implicit type? So I can:
x: int = 123 // explicit type
x = 123 // implicit type
Wouldn’t this be more sane?
P.S. I might be mistaken that I created this as an issue. Should have created this as discussion. I just might be disappointed with some of the decisions, and I have to deliver it somehow clear. And I used wording «sane» which might be offensive, but that’s exactly the word from website homepage, so… But I still value everyone’s work of course, just to be clear.
P.P.S. Yes, :=
isn’t PHP, it’s Pascal… which isn’t better
from odin.
Yeah, there’s normally some keyword for declaration like var x = 123
Which is less ambiguous than x := 123
– which feels like just an assignment but turns out it’s declaration? But it might be just me of course. After all, such an opinion depends on the language a person comes from. To me var x = 123
is less ambiguous
Btw, as a question from complete stupid person, can anyone tell me why wouldn’t compiler just do this:
- If it’s first occurrence, it’s declaration
- otherwise, it’s assignment?
I believe there is an answer, just asking out of curiosity. Same ambiguity again? So :=
you think is most un-ambiguous way of declaration, even clearer than var x = 123
? No offense, just curious.
from odin.
First question.. now, x = 123
has more than one meaning and increases ambiguity.
Second question.. If you were to switch to var x = 123
, how do you define an explicit type?
from odin.
var x = 123 // implicit
var x: int = 123 // explicit
from odin.
The first :
signifies that this is a declaration. The following =
signifies a runtime value assignment. This is well defined and not ambiguous. There is only 1 meaning -- you just have to learn what the symbols mean. Your proposal adds a new keyword to the language when none is necessary.
I think you should consider your own question about the perils of removing control from users as to when a variable is declared. The discord channel is a better place to discuss this though.
from odin.
Okay, I see. However, it still adds an unnecessary keyword. If you look at some Odin code, you will see nothing else really works in that order. You will also see that the :
operator nicely unifies procedure definitions with the same syntax. These are separate ideas and (often confusing) syntax in other languages (looking at you C).
// a constant
A :: 5
a_proc :: proc(x: int) -> int {
return x
}
// a variable
my_proc: proc(x: int) -> int
my_int: 5
Adding var
would also introduce ambiguity in procedure declarations vs variables. In this particular area, Odin is light-years ahead of C as it is all one unified idea. Adding more complication here is a regression.
from odin.
So is that right that you both think:
- declarations vs assignment difference introduces ambiguity
- declarations and assignment via same syntax introduces ambiguity
Even though they're literally two opposite ways to declare variable / assign a value, – and both are ambiguity to you? Therefore, that's your honest opinion that's x := 123
is the most non-ambiguous to you way to declare? It's still different to assignment which is just x = 123
, though. Do you mean this, like, a lesser evil? To me it doesn't seem like lesser evil at all. It seems like more evil than either of two above, because it's both ambiguous and ugly.
One positive thing though, that I might agree with you, is that the fact it doesn't need additional keyword token, which is a little better to compiler... I guess? That's infamous topic of every compiled language probably: «Should we do the language for human, or for a compiler?». Obviously, the right answer is that there should be a balance between these two. We probably shouldn't do everything for human if it's worsening the compiler performance drastically. But in this particular case, I think var x = 123
is superior to x := 123
, it's worth it, even though it requires additional keyword for compiler to handle.
From compiler viewpoint, yes, probably better to parse :=
, but here are the other things to consider:
- Ugly, emotionally. Anyone new, when seeing the language on homepage with some Pascal syntax they learned in school, would instantly be frightened probably. Not that this should be a priority of course, to please everyone possible, but something to consider too.
- Ugly, practically. Writing the actual language itself, if one still decided so, it will be harder to see in the code where variables are declared vs assigned because it's so easy to skip this little
:
in the code compared tovar
, and that is a bit of deal-breaker to me, makes me unwilling to start to learn and write in this language
On the other hand, if there's some formatter requiring an explicit declaration like x: int = 123
, then this question is more or less solved to me. I just hoped it would be solved at language level rather than some tooling around it (which is not present yet, I guess?).
from odin.
Related Issues (20)
- Declaring proc that does nothing in defer block causes backend crash HOT 2
- or_else not compiling with function returning single bool or ptr value HOT 1
- `-vet-unused-variables` produces unnecessary errors when variable is used as a index HOT 8
- X11 bindings broken/annoying HOT 3
- Incorrect case selected in switch on Maybe(^T) HOT 2
- odin check fails to detect a type error HOT 1
- Segfault during type checking HOT 1
- Performing && or || on boolean arrays causes compiler to panic HOT 1
- "Maybe" assignment failing on struct initilization HOT 6
- Breaking from a loop in defer causes a compiler seg fault
- Suggest Slice Operator When Using [dynamic] on Polymorphic Type Parameter Looking for Slice
- A slice marked with @(rodata) can still be modified (and won't throw an error)
- When Accessing a Slice in an rodata struct, it can still be modified HOT 1
- @(rodata) doesn't work with slices of unions HOT 1
- Compiler crashes when building with spall HOT 4
- Compiler crashes on an array of values with different types, which has "using"
- Using all implicit swizzle fields on a array pointer causes CPP assertion.
- Syntax errors when declaring a multi-line procedure
- Problems with precision when using `linalg.angle_between`
- JSON Parsing Issue (Float field)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from odin.