The Crystal programming language | http://crystal-lang.org | Fund Crystal's development: http://is.gd/X7PRtI | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/
<raz> hm, i think it relates to designing for experts vs mortals. of course it's not a problem for compiler & stdlib authors. they intuitively structure their code to avoid nil to begin with. the mortals (like me) are often not that smart. so they more frequently end in a situation where they have to choose between ugly (not_nil / try), trappy (if =) or going back and refactoring all the things.
<raz> it compounds because shards and external data often also don't avoid nil as much as they should/could.
raz, i always said assignment should require parentheses around it, then it's a bit more visible
<raz> in many (most?) languages assignment in conditional is a compiler warning or even error. and i think for good reason.
that is not true though
<raz> oprypin_, straight-shoota: well i guess the formal complaint would be because it's a trap (typo risk). not sure how much that matters in practice as the compiler probably catches most accidental mix-ups. but my personal complaint is more about readability. i don't expect assignments within an
if, have to double-take almost every time i see it. kotlin's solution feels cleaner to me, they made the safe-nav operators convenient (even added elvis-op) and
<raz> assigment in conditional is verboten.
<raz> oprypin_: well i think it's at least a warning in most languages & linters that i know. golang allows it but then scopes the var to the if-block. it just seems odd that crystal promotes something that is widely considered a gotcha to a suggested pattern. :/
<raz> oprypin_: rubocop seems to agree with your idea, too https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Lint/AssignmentInCondition
<straight-shoota> When I write
if foo = some_nilable I think that very clearly expresses the intent that the branch depends on some_nilable being non-nil.
<straight-shoota> You could write
foo = some_nilable; if foo as well. And I definitely prefer that if foo is used outside the conditional as well.
<straight-shoota> But if
foo is just used as non-nil inside the branch, combining it with the condition itself seems like a good idea to me.
<raz> yup would agree it's subjective. mostly bumping into it because i'm in a rather nil-ridden environment atm (working with protobuf where everything can be nil basically at any time). i just feel like the current nil-handling still reflects wishful thinking a bit too much over practicality. the argument for keeping
.not_nil! and .try as unwieldy as they are was to motivate users to avoid them. but then at the same time we have this little backdoor (if =)
<raz> which allows avoidance throug a questionable pattern. imho the kotlin way of making safe-nav convenient is a better compromise.
<straight-shoota> *kotlin
<raz> https://kotlinlang.org/docs/null-safety.html#the-operator - similar to crystal but syntax is more convenient, closer to ruby in that regard (
?. instead of .try &)
<raz> (eh sorry, my link hit a bit too low, you gotta scroll up a bit to "Safe calls")
<straight-shoota> An equivalent alternative to
if foo = some_nilable would be foo = some_nilable; if foo (or maybe a dedicated assignment operator as @asterite mentioned)
<raz> (as mentioned in kotlin
if foo = anything is not allowed at all. i imagine they may have had a similar discussion in their past)
<straight-shoota> Hm, I've never used
if foo = nilable instead of foo.try {}
<raz> when it's followed by a longer block, or worse, when the var is then used outside of that block, it can be quite confusing
<xyhuvud> you don't get to avoid it for @instance variables anyhow, so you might as well embrace it.
<straight-shoota> TIL *_with_index is not limited to integer index
<straight-shoota> >> (0..4).each_with_index('a') { |x, i| puts "#{i}: #{x}" }
<DeBot_> straight-shoota: a: 0 - more at https://carc.in/#/r/blo8
<straight-shoota> printing ordered lists (like
list-style-type: lower-alpha in CSS)
<raz> that might get a bit nasty after 25 items ;P
<straight-shoota> replacing
i += 1 by i = i.succ makes it even more generically useful
<straight-shoota> all good with succ + String: https://carc.in/#/r/blod
I tried
brew install crystal and with --build-from-source
I am not that familiar with generics in Crystal, and I'm wondering if they are similar to Nim or Rust in that I can restrict a generic type parameter inline. The following is a Nim function definition, where
T is restricted to be of type Vec, which is used for both arguments and the return type. How can I do similar with Crystal, without a type alias or relying on the inferred call site types?proc abs[T: Vec](o: var T, v: T): var T = ...
i.e. not something the lang supports atm
<straight-shoota> This would be an example of a macro-based type restriction: https://github.com/crystal-lang/crystal/blob/13dd77ef01c0d55f2d43372f97c648ff81c737d9/src/slice.cr#L745-L748