scala/scala

Discord is now Scala’s main chat platform. Please join us at https://discord.com/invite/scala

Ghost

@ghost~54f4b69115522ed4b3dcb16d

@jpallas on unused implicit enrichment, I suggested -Xlint to warn if an import is unused. For implicit scope, this is why folks complain about coherence, there's no way to verify your extension is used and is the only such extension in scope.

Raul Rodriguez

@raul782

thanks @m-sp

Naftoli Gugenheim

@nafg

@avremel do you understand the desugared version?

Avremel Kaminetzky

@avremel

@nafg I don't understand .map(aFacet => facetName -> facetArr)

Klas Segeljakt

@segeljakt

Is there any good example of when Scala’s type inference is not smart enough?

Joe Pallas

@jpallas

@som-snytt I certainly see a similarity to coherence in that the problem really is non-local. When the extension is compiled, only the type being extended is visible to the compiler, so it can only complain about extension methods shadowed at that level of the hierarchy. When the client is compiled, the compiler could complain that the extension is imported but unused, but if any other extension methods are used, there's nothing to complain about.

trepidacious

@trepidacious

@avremel I can't say I understand the whole thing because I haven't read through the data model, but that maps each aFacet in the facetArr (which I guess is an array?) into facetName -> facetArr, which is just (facetName, facetArr), a tuple of 2 elements. The -> syntax is often used when creating a map from tuples, since it looks nice :)

Avremel Kaminetzky

@avremel

@trepidacious so would it make sense that is mapping aFacet to the facetArr?

trepidacious

@trepidacious

@avremel TBH I don't understand that code, because I don't know what the data is, or what it's trying to do, but that's what the syntax does ;)

Avremel Kaminetzky

@avremel

thx

Miguel Pérez Pasalodos

@mpasa

Question: what's the difference between -X and -Y options? I know X options come from Java's non-standard options, but I've never asked myself what the Y stands for.

Rob Norris

@tpolecat

@klassegeljakt you have to define what you mean by "not smart enough" … scala can often infer a type, it just may be more general or more specific than the type you want it to infer. Subtyping complicates things and places some limits on what's possible.

Klas Segeljakt

@segeljakt

I mean, when do you need to be more explicit than what you would be in Hindley Milner

Ichoran

@Ichoran

@mpasa - -Y is even less standard than -X.

Klas Segeljakt

@segeljakt

I’m trying to compare it to Rust’s type inference

Ichoran

@Ichoran

@klassegeljakt - H-M doesn't cover subtyping in its full glory (including covariant and contravariant type parameters)

Rob Norris

@tpolecat

I don't know much about Rust's type system. @Ichoran might have an example.

Klas Segeljakt

@segeljakt

Rust’s type inference is Hindley Milner + some additions to support subtyping

Ichoran

@Ichoran

My recollection is that Rust doesn't use straight-up H-M either. Nor does Haskell, actually, I think.

Miguel Pérez Pasalodos

@mpasa

@Ichoran :smile: Is it Scala specific? Can a -Y flag be converted into a -X?

Ichoran

@Ichoran

@mpasa - Yes, it's Scala specific; these are flags for the Scala compiler.

Klas Segeljakt

@segeljakt

in Scala, can the type of a value be inferred based on how it is used later in the code?

Ichoran

@Ichoran

@klassegeljakt - No, it's determined within the same expression (with some extra rules about how long types can stay unknown).

Klas Segeljakt

@segeljakt

OlegYch

@OlegYch

variables are uncommon in scala

Klas Segeljakt

@segeljakt

maybe that is the difference, in Rust you can do

let x = 3.3;
let y: f32 = x;
let z: f64 = x; // ERROR x is of type f32

I think

Rob Norris

@tpolecat

Well you can do that in Scala if f32 and f64 both conform with the inferred type of x.

But the type of x is inferred before it ever looks at y.

Klas Segeljakt

@segeljakt

Rob Norris

@tpolecat

Inference in Scala is primitive, and not only due to limitations of the formalism (such as it is).

OlegYch

@OlegYch

pretty sure let y is of no consequence there

Rob Norris

@tpolecat

It's designed to hit the common cases relatively efficiently.

Klas Segeljakt

@segeljakt

let x = 3.3;
let y: f64 = x;
let z: f32 = x; // ERROR x is of type f64

OlegYch

@OlegYch

Ichoran

@Ichoran

It's different in Scala.

Klas Segeljakt

@segeljakt

I can test

does the Scala inference algorithm have a name?

or is it specific to Scala

Rob Norris

@tpolecat

It's an implementation detail. It's not specified.

Ichoran

@Ichoran

val x = 1    // now x has type Int
val y: Short = x   // fails
val z: Long = x  // succeeds

And it works that way because of numeric widening.

Otherwise it would fail both lines.

Rob Norris

@tpolecat

Numeric types confuse the discussion I think because you have to think about weak conformance.

Ichoran

@Ichoran

Another case of the locality of type inference occurs with cases like def foo[A, B](a: A)(b: B, f: A => B) = ...

Ghost

@ghost~54f4b69115522ed4b3dcb16d

@mpasa with two X, you get a female option, but with a Y you get a male. There's a general sense that Y is more expendable; also, you can't rely on a Y when you need it. Sometimes a Y will transition to an X, and suddenly becomes pleasant to work with.

Ichoran

@Ichoran

Here, once you get past a: A, the compiler has decided what A is supposed to be. It can't use the stuff in f: A => B to help it decide.

Derek Wickern

@dwickern

so rust decides on the type of x the first time it's used?

Ichoran

@Ichoran

On the one hand that's bad, because you have to manually widen types. On the other hand, it's good because you can nail down your function types based on earlier arguments.

I think bad outweighs good, but it's not all purely bad :P

Where communities thrive

People

Repo info

Activity