Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 01:29
    HertzDevil closed #12519
  • 01:29
    HertzDevil closed #12517
  • 01:24
    HertzDevil synchronize #11840
  • 01:20
    HertzDevil synchronize #12364
  • Sep 24 20:37
    beta-ziliani labeled #12522
  • Sep 24 20:37
    beta-ziliani labeled #12522
  • Sep 24 20:37
    beta-ziliani opened #12522
  • Sep 24 17:15
    mattrberry opened #12521
  • Sep 24 17:15
    mattrberry labeled #12521
  • Sep 24 16:57
    asterite synchronize #12520
  • Sep 24 16:32
    asterite labeled #12520
  • Sep 24 16:32
    asterite labeled #12520
  • Sep 24 16:32
    asterite opened #12520
  • Sep 24 15:07
    Blacksmoke16 labeled #12518
  • Sep 24 13:35
    zw963 edited #12519
  • Sep 24 13:35
    zw963 opened #12519
  • Sep 24 13:35
    zw963 labeled #12519
  • Sep 24 13:25
    zw963 labeled #12518
  • Sep 24 13:25
    zw963 opened #12518
  • Sep 24 10:34
    straight-shoota reopened #11340
From IRC (bridge bot)
@FromIRC
<raz> it compounds because shards and external data often also don't avoid nil as much as they should/could.
oprypin
@oprypin:matrix.org
[m]
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

From IRC (bridge bot)
@FromIRC
<straight-shoota> raz, why do you think assignment in a condition is problematic?
From IRC (bridge bot)
@FromIRC
<raz> oprypin_: +1 - i think that would make it less trappy at least
From IRC (bridge bot)
@FromIRC
<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. :⁠/
From IRC (bridge bot)
@FromIRC
<raz> oprypin_: rubocop seems to agree with your idea, too https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Lint/AssignmentInCondition
From IRC (bridge bot)
@FromIRC
<straight-shoota> I guess this is a very subjective topic. I don't have any issues with such assignments, it seems logical to me.
<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.
From IRC (bridge bot)
@FromIRC
<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.
From IRC (bridge bot)
@FromIRC
<raz> (discl: then again, i don't have much exp with kotlin. perhaps their solution in turn leads to less "nil-avoidance" in the community because they don't hurt as much to deal with. hm.)
From IRC (bridge bot)
@FromIRC
<straight-shoota> what's cotlin's solution?
<straight-shoota> *kotlin
From IRC (bridge bot)
@FromIRC
<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")
Ary Borenszweig
@asterite
Regarding if foo = ..., I proposed being able to use if foo := bar in conditionals to avoid this issue, but it wasn't well received. I think it would have made things much clearer for some
From IRC (bridge bot)
@FromIRC
<straight-shoota> raz, try or a safe navigation operator can't really replace a proper conditional. They are related but different use cases IMO.
<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)
From IRC (bridge bot)
@FromIRC
<raz> yup true. but with more convenient navigation fewer people would reach for if foo = nilable. i think atm that mainly happens because they want to avoid the ugly .try or .not_nil! that would otherwise be required.
<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 {}
From IRC (bridge bot)
@FromIRC
<xyhuvud> why would if foo = nilable be bad in the first place?
<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
From IRC (bridge bot)
@FromIRC
<raz> that's neat, now we just need a use-case for it :⁠D
<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
From IRC (bridge bot)
@FromIRC
<raz> ha!
Taupiqueur
@alexherbo2
how to get Crystal on macOS M1 ?
I tried brew install crystal and with --build-from-source
George Dietrich
@Blacksmoke16
mfiano
@mjfiano:matrix.org
[m]
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 = ...
George Dietrich
@Blacksmoke16
not in that way, would have to be within one of the methods in a macro
i.e. not something the lang supports atm
mfiano
@mjfiano:matrix.org
[m]
I see, thanks.
George Dietrich
@Blacksmoke16
From IRC (bridge bot)
@FromIRC
<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
Ary Borenszweig
@asterite
another way would be to use a helper method: def foo(x : T, v : T) : T; foo_helper(x, v); end; def foo_helper(x : Vec, v : Vec). So both have to be the same type, and both have to be Vec
mfiano
@mjfiano:matrix.org
[m]
Yeah I'm not a fan of making the body less readable to restrict a type or two