Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A strawman for aggregate literals #21993

Draft
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Nov 20, 2024

A test case that shows that we can have an "inline type class" that allows to use a typeclass-based scheme for sequence literals where instances can be created with macros.

@odersky odersky marked this pull request as draft November 25, 2024 11:09
A test case that shows that we can have an "inline type class" that allows
to use a typeclass-based scheme for sequence literals where instances can
be created with macros.
Also: Move test to run
We now don't try to instantiate selected type variables. Instead, we use a default as fallback if
the expected type is underspecified according to the definition in Implicits. This is
simpler and more expressive.
@soronpo
Copy link
Contributor

soronpo commented Nov 25, 2024

From the doc I understand that implicit conversions are not applicable. Is weak conformance applicable?
What is expected for val oneTwoThreeDbl: Seq[Double] = [1, 2, 3]?

@odersky
Copy link
Contributor Author

odersky commented Nov 25, 2024

The successor of weak conformance (int literal widening) is usually applicable. That follows from the fact that SeqLiterals expand to varargs and varargs do perform that widening.

@@ -278,6 +278,7 @@ SimpleExpr ::= SimpleRef
| ‘new’ ConstrApp {‘with’ ConstrApp} [TemplateBody] New(constr | templ)
| ‘new’ TemplateBody
| ‘(’ ExprsInParens ‘)’ Parens(exprs)
| ‘[’ ExprInBrackets ‘)’ SeqLiteral(exprs, TypeTree())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| ‘[’ ExprInBrackets ‘)’ SeqLiteral(exprs, TypeTree())
| ‘[’ ExprInBrackets ‘]’ SeqLiteral(exprs, TypeTree())

just noticed while having a look

Also, test infix operations taking [...] as a right operand.
Some corrections in docs, fix typos, drop unused code.
@bishabosha
Copy link
Member

bishabosha commented Nov 27, 2024

I got a crash in the repl by just having [] as the input to the prompt

@bishabosha
Copy link
Member

Also, maybe this is expected as its just for testing, but some of the instances for ExpressibleAsCollectionLiteral are "going to be ambiguous in 3.7":

scala> val m: Set[Int] = [1,2,3]
1 warning found
-- Warning: --------------------------------------------------------------------
1 |val m: Set[Int] = [1,2,3]
  |                   ^
  |Given search preference for scala.compiletime.ExpressibleAsCollectionLiteral[Set[Int]] between alternatives
  |  scala.compiletime.ExpressibleAsCollectionLiteral.bitsetFromLiteral.type
  |and
  |  (scala.compiletime.ExpressibleAsCollectionLiteral.setFromLiteral :
  |  [T]: scala.compiletime.ExpressibleAsCollectionLiteral.setFromLiteral[T])
  |will change.
  |Current choice           : the first alternative
  |New choice from Scala 3.7: none - it's ambiguous
val m: Set[Int] = BitSet(1, 2, 3)

@odersky
Copy link
Contributor Author

odersky commented Nov 27, 2024

@bishabosha In fact, the given instances are set up so that it works properly only from 3.7 onwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants