Discord is now Scala’s main chat platform. Please join us at https://discord.com/invite/scala
val fileStream = getClass.getResourceAsStream(path)
val lines = Source.fromInputStream(fileStream).getLines()
println(lines.length)
lines.foreach(println)Because when I comment out the
print(lines.length) it prints the lines.
Hello, looks like the export clause does not exports the default values of a function's parameters. Using Scala 3.1.1-RC1 on
scalastie :
class A(s: String):
def greeting(name: String = s) = s"Hello $name"
class B:
val a = A("You")
export a.*
val b = B()
println(b.a.greeting()) // works
println(b.greeting("John")) // works
println(b.greeting()) // nope !Is it a known restriction ?
toList after getLines so you can load all the data in memory an being able to use it multiple times.
WeakTypeTag. Using typeSignature, I get the following for Int field - => Int. I want to inspect using something like in =:= typeOf[Int]. I'm a bit confused on what i should be doing?
- Use proper types, rather than a
List[List[Any]]where the inner list always has two elements of different types; use aList[(Int, A)] - The Scaladoc is your friend: https://www.scala-lang.org/api/current/index.html
@Sakitha
thought it was a dumb question to ask
There are no dumb questions, there are fools that don't ask.
Is it bad to have a for loop that wouldn't yield a value but instead change a predefined array?
Well, it depends on a lot of things, specially what is your definition of "bad".
- Shared mutability can become problematic when you have concurrency.
- Immutable solutions powered by the stdlib rich operations are usually more maintainable than a mutable loop (although, this is somewhat subjective)
Thus, if all the code base is immutable I would rather make each method immutable even if their contained mutability is fine just for the sake of consistency.
I just want to learn the functional way of coding, Thank you for the information and for the example
Sure!
No worries and welcome to the community!
If you can and want; I would recommend joining the discord server instead: https://discord.gg/7aUsmzyD
type Id = Int | Long | UUID
trait MappedTo[+T <: Id] extends Any:
def value: T
type GetType[T <: MappedTo[_]] = T match
case MappedTo[Int] => Int
case MappedTo[Long] => Long
case MappedTo[UUID] => UUID
class Extract[T <: MappedTo[_]](val map: T => GetType[T])
given extract[T <: MappedTo[_]]: Extract[T] = new Extract[T](_.value) // ERRORFound: _$1.T
| Required: GetType[T²]
|
| where: T is a type in trait MappedTo with bounds <: Id
| T² is a type in given instance extract with bounds <: MappedTo[?]
|
|
| Note: a match type could not be fully reduced:
|
| trying to reduce GetType[T]
| failed since selector T
| does not match case MappedTo[Int] => Int
| and cannot be shown to be disjoint from it either.
| Therefore, reduction cannot advance to the remaining cases
|
| case MappedTo[Long] => Long
| case MappedTo[java.util.UUID] => java.util.UUID
So, in val map: T => GetType[T], T is unknown and therefore the match type fails.
I guess I'm looking for a lazy Match Type if that makes sense, or is even possible.
4 replies
I just found some interesting behavior in Scala 3.
infix case class ~[T1, T2](_1: T1, _2: T2)
def main(): Unit =
val ab: Int ~ Int = ~(1, 3)
println(ab)results in value unary_~ is not a member of (Int, Int). In other words, ~(1, 3) is getting parsed as unary_~ plus Tuple2(1, 3) instead of function name ~ + arguments (1, 3). Is this a change in how Scala 3 parses, a known bug, or have I discovered something interesting?
~.apply(1, 3) seems to work as a workaround, but is a little annoying.
~ is already defined as object ~ in /path/to/the/scala/file