Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ólafur Páll Geirsson
    @olafurpg
    @Koroeskohr that could be because var inside traits desugar into private fields with a setter method
    Nicolas Rinaudo
    @nrinaudo
    I'm hitting something that feels like a bug: with Scala 2.13, the StringPlusAny wart will trigger on string interpolation
    is that working as intended?
    Greg Pfeil
    @sellout
    @nrinaudo I feel like that is the correct behavior (unless you’re interpolating a String).
    Nicolas Rinaudo
    @nrinaudo
    oh, it's been pointed out that there's actually a bug open for that: wartremover/wartremover#447
    @sellout I think it's debatable. You might want to disallow string interpolation with non string members, but:
    • that seems harsh!
    • it's really odd that it'd trigger StringPlusAny
    I think I understand the purpose of StringPlusAny, and that's not it
    (but I might be wrong in that)
    Greg Pfeil
    @sellout
    What is the purpose if not to avoid automatic conversion to String? Like, how is "some ${foo} string" different from "some " + foo + " string"?
    Nicolas Rinaudo
    @nrinaudo
    well, because I'd assume it to be equivalent to "some " + foo.toString + " string", which I would have thought triggered ToString
    Greg Pfeil
    @sellout
    In my own code bases, anything that resulted in a call to toString would be a bug, but I know that my use case is not everyone’s.
    Nicolas Rinaudo
    @nrinaudo
    maybe I'm just not thinking about this right
    oh, sure, that's not what I'm arguing. I'm saying that it feels like the wrong wart is triggered
    Greg Pfeil
    @sellout
    Ah, I see.
    So, there’s another wart to catch use of toString.
    Nicolas Rinaudo
    @nrinaudo
    yeah. ToString
    If that were triggered by string interpolation, I'd get it. But StringPlusAny feels confusing for newcomers - it's another of these failures where the root cause is hidden
    and... does it mean that you basically do not use string interpolation, by the way?
    Greg Pfeil
    @sellout
    Yeah, I don’t. Not for any good reason. But I wonder if there was a change in Scala 2.13 to have interpolation expand to + foo + instead of + foo.toString +? It seems like that would be a simplification that could prevent diverging semantics – i.e., it means that interpolation and concatenation both have the same conversion semantics, rather that having interpolation do its own string conversion, which could get out of sync with that for concatenation. Since both are currently defined to use .toString, it wouldn’t change behavior, but could change how it’s seen by WartRemover.
    Nicolas Rinaudo
    @nrinaudo
    I believe that's the case, yes
    @som-snytt @nrinaudo string interpolator converts to string + now.
    If you didn't like string interpolation before, you won't ike string_+ either. It's all stringifications.
    Greg Pfeil
    @sellout
    I think this is a case where those two warts should be a single thing like ImplicitStringConversion. Having each wart catch one low-level pattern makes these things a bit more fragile, where an “invisible” change becomes exposed.
    I use Warts.AllBut(Any, Nothing) – but I guess most people probably want something more fine-grained than that 😆
    som-snytt
    @som-snytt
    In the spirit of TMI, they wanted to make s-interpolator more efficient, so instead of a loop calling stringbuilder.append, you get a "" + arg expression that the platform can optimize. Maybe StringBuilder.append(Object) is the missing wart.
    Warts.andAll.
    If you use Warts.andAll, your code still passes the build even if it's really ugly.
    Nicolas Rinaudo
    @nrinaudo
    But I like string interpolation:(
    Greg Pfeil
    @sellout
    @nrinaudo You can still use string interpolation – just "some ${foo.show} string".
    som-snytt
    @som-snytt
    Is it worth adding that you can have a show interpolation that takes implicits? You can call it s"" for show.
    Greg Pfeil
    @sellout
    Oh, right! That’s a thing that exists already. I actually don’t use Show, either – just explicit functions that result in a String. But yeah, that’s definitely a useful thing to remember that would also silence the wart.
    udalrich
    @udalrich
    It seems difficult to use MutableList with Warts.unsafe. val list:MutableList[Integer] = MutableList(); list += 4 fails to compile, as list += 4 does not return unit. I haven't tried, but I suspect var list = List[Integer](); list = list + 4 would fail the Var wart
    ritschwumm
    @ritschwumm
    @udalrich Warts.unsafe and MutableList sound like a weird combination - like making absolutely sure there's not a single knife in the house to so the kids won't ever hurt themselves, and then buying them a chainsaw as a birthday present...
    udalrich
    @udalrich
    It seemed like Wars.unsafe was a recommended/good if you can get there setting. My use case is this. I have a bunch of objects from a 3rd party library. I need to remember which ones I have done a particular action with, and I can't query the object to find out if I did it. So I have code like def doStuff(x: Thing) = { x.doThing(); list.add(x) } so that list holds the Things I have operated on. How would I write that with Warts.unsafe?
    udalrich
    @udalrich

    I had code that did

    if (list.isEmpty) {
      stuff(list.head, list.tail)
    } else {
      otherStuff()
    }

    Warts.TraversibleOpts told me to use headOption instead. Warts.OptionPartial won't like

    list.headOption.ifPresent(stuff(_, list.tail)).orElse(() => otherStuff()).get

    but I don't see another way to do it. getOrElse(otherStuff()) is wrong, because calling otherStuff is wrong if the list is not empty.

    I suspect the problem is that Option should have a getOrElse that takes a function to build the result, not just getOrElse(T). Is there another way to do this?

    ritschwumm
    @ritschwumm
    @udalrich how about this?
    list match {
      case Nil    => otherStuff()
      case h :: t => stuff(head, tail)
    }
    and btw getOrElse does take a function under the hood: the type of its parameter is =>T and not T, so the parameter will not be evaluated in the nonEmpty case
    udalrich
    @udalrich
    That would work. I'm new enough to scala that writing getOrElse(otherStuff()) looks like it should always call otherStuff.
    Stefan E. Mayer
    @stefanerwinmayer
    Hello, Is there a way to make wartremover work with bloop?
    David Roon
    @adridadou
    hi everyone! I have a question. I’m trying to use the rule NonUnitStatement but I have an issue with parboiled rules
    it seems that it sees every rule as a NonUnitStatement
    is there a way how to solve that ?
    David Roon
    @adridadou
    looks like the issue is that because parboiled is using macros, the code seems wrong but isn’t
    David Roon
    @adridadou
    I have now another issue that I find interesting. It seems like in Scala 2.13, Seq[T] extends JavaSerializable so it triggers the javaSerializable error
    works fine in scala 2.12
    Andrey Ivanov
    @a-nigredo
    Hi all, is it possible for SuppresWarning with custom wart?
    I'm using last version of wartremover
    nigredo-tori
    @nigredo-tori
    @a-nigredo, the warts handle SuppressWarnings themselves. So your wart has to support that.
    Andrey Ivanov
    @a-nigredo
    @nigredo-tori thanks
    Dmitrii Kostianoi
    @DStranger

    Hi guys, I have a question, although it might be more of an sbt-in-general type of question, but anyway.
    I have a multi-project build for which I'd like to enable wartremover in one place.
    I'd like to use something like the following, but it doesn't seem to work.

    ThisBuild / Compile / wartremoverErrors := Warts.all
    ThisBuild / Test / wartremoverErrors := Seq.empty

    I can use the common settings approach, but there must be a better solution.

    nigredo-tori
    @nigredo-tori
    @DStranger, please run inspect foo/Compile/wartremoverErrors in your SBT console (replacing foo with your project identifier), and post the result here.