Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 18 22:28
    straight-shoota closed #11751
  • Jan 18 17:33
    straight-shoota milestoned #11751
  • Jan 18 16:48
    Blacksmoke16 labeled #11753
  • Jan 18 16:42
    yxhuvud labeled #11753
  • Jan 18 16:42
    yxhuvud opened #11753
  • Jan 18 13:52
    straight-shoota synchronize #11751
  • Jan 18 13:34
    HertzDevil opened #11752
  • Jan 18 13:34
    HertzDevil labeled #11752
  • Jan 18 13:34
    HertzDevil labeled #11752
  • Jan 18 13:34
    HertzDevil labeled #11752
  • Jan 18 12:54
    straight-shoota synchronize #11751
  • Jan 18 12:48
    straight-shoota labeled #11751
  • Jan 18 12:48
    straight-shoota opened #11751
  • Jan 18 12:45
    straight-shoota synchronize #11716
  • Jan 18 10:38
    straight-shoota milestoned #11742
  • Jan 18 01:09
    straight-shoota closed #11747
  • Jan 18 01:09
    straight-shoota closed #11745
  • Jan 17 19:16
    straight-shoota synchronize #11716
  • Jan 17 19:11
    straight-shoota synchronize #11715
  • Jan 17 18:34
    straight-shoota milestoned #11747
George Dietrich
@Blacksmoke16
fair enough
mfiano
@mjfiano:matrix.org
[m]
But I'll think about it. You have given me nothing but good suggestions this week and I am a bit tired now and about to quit, so we'll see. Thank you
George Dietrich
@Blacksmoke16
o/
on an unrelated note, https://play.crystal-lang.org/#/r/blio is this output expected?
looks to be a regression in 0.31.0
Matthew Berry
@mattrberry
Out of curiosity, are there downsides to a type system that supports something like this? https://carc.in/#/r/bljn
Quinton Miller
@HertzDevil
From IRC (bridge bot)
@FromIRC
<raz> if foo = bar should be a syntax error
From IRC (bridge bot)
@FromIRC
<raz> i keep seeing it in crystal code used as a workaround for .try and .not_nil!. people want their code to be fluent to read, but replacing warts with traps is not a solution :⁠(
Quinton Miller
@HertzDevil
they are fluent to read unless you come from c
even in c++ if (auto y = dynamic_cast<Derived *>(x)) is perfectly fine and fluent
From IRC (bridge bot)
@FromIRC
<raz> in many (most?) languages assignment in conditional is a compiler warning or even error. and i think for good reason.
<raz> no, that's a warning C4706
Quinton Miller
@HertzDevil
and in many, they aren't
also for good reasons
c++ compilers are not required to emit that warning so it's not the language that's responsible here
you could see if ameba warns about that, but crystal itself should not disallow if foo = bar
From IRC (bridge bot)
@FromIRC
<raz> i think the bigger problem is that crystal not only allows but even encourages it
Quinton Miller
@HertzDevil
if you think that's a bigger problem you could try to replace all occurrences in the standard library plus the compiler and see how many others think disallowing that is the job of the compiler and not a linter
From IRC (bridge bot)
@FromIRC
<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.
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.