Scala Programming Language
  1. Scala Programming Language
  2. SI-5712

support dependent argument types for constructor parameter lists (in the same way as for methods)

    Details

      Description

      scala> import scala.tools.nsc._
      import scala.tools.nsc._
      
      scala> def mkReifier(global: Global)(typer: global.analyzer.Typer) = typer
      mkReifier: (global: scala.tools.nsc.Global)(typer: global.analyzer.Typer)global.analyzer.Typer
      
      scala> class Reifier(global: Global)(typer: global.analyzer.Typer) { }
      <console>:10: error: not found: value global
            class Reifier(global: Global)(typer: global.analyzer.Typer) { }
                                                 ^
      

        Issue Links

          Activity

          Hide
          Jason Zaugg added a comment -

          Just happened across this looking into SI-5070, it struck me that it might need to be expanded for dependent constructor types.

          override def isImmediatelyDependent = (sym ne NoSymbol) && (sym.owner.isMethod && sym.isValueParameter)
          
          Show
          Jason Zaugg added a comment - Just happened across this looking into SI-5070 , it struck me that it might need to be expanded for dependent constructor types. override def isImmediatelyDependent = (sym ne NoSymbol) && (sym.owner.isMethod && sym.isValueParameter)
          Hide
          Adriaan Moors added a comment - - edited

          I wonder why we're using an outer namer for parameter accessors.
          Commenting out these lines fixes the test case.

              def namerOf(sym: Symbol): Namer = {
                val usePrimary = sym.isTerm && (
          //           (sym.isParamAccessor)
          //        ||
                  (sym.isParameter && sym.owner.isPrimaryConstructor)
                )
          
                if (usePrimary) createPrimaryConstructorParameterNamer
                else innerNamer
              }
          

          Here's a self-contained test case that also makes sure the constructor's type parameters stay in scope.

          class Global {
            class Typer[T]
          }
          
          class Reifier[T](global: Global)(typer: global.Typer[T])
          
          object Test {
            def mkReifier[T](global: Global)(typer: global.Typer[T]) = typer
          }
          
          Show
          Adriaan Moors added a comment - - edited I wonder why we're using an outer namer for parameter accessors. Commenting out these lines fixes the test case. def namerOf(sym: Symbol): Namer = { val usePrimary = sym.isTerm && ( // (sym.isParamAccessor) // || (sym.isParameter && sym.owner.isPrimaryConstructor) ) if (usePrimary) createPrimaryConstructorParameterNamer else innerNamer } Here's a self-contained test case that also makes sure the constructor's type parameters stay in scope. class Global { class Typer[T] } class Reifier[T](global: Global)(typer: global.Typer[T]) object Test { def mkReifier[T](global: Global)(typer: global.Typer[T]) = typer }
          Hide
          Adriaan Moors added a comment - - edited

          Lukas explains: we shouldn't see fields in the constructor signature, but we should see the parameter accessors.

          Show
          Adriaan Moors added a comment - - edited Lukas explains: we shouldn't see fields in the constructor signature, but we should see the parameter accessors.
          Hide
          Grzegorz Kossakowski added a comment -

          Unassigning and rescheduling to M7 as previous deadline was missed.

          Show
          Grzegorz Kossakowski added a comment - Unassigning and rescheduling to M7 as previous deadline was missed.
          Hide
          Eduardo Pareja Tobes added a comment -

          just curious, why is this no longer considered a bug but an improvement?

          Show
          Eduardo Pareja Tobes added a comment - just curious, why is this no longer considered a bug but an improvement?
          Hide
          Adriaan Moors added a comment -

          Dependent method types were an improvement as well. This is an improvement to support dependent constructor types, which were never implemented. So, technically, they can't be buggy

          Show
          Adriaan Moors added a comment - Dependent method types were an improvement as well. This is an improvement to support dependent constructor types, which were never implemented. So, technically, they can't be buggy
          Hide
          Eduardo Pareja Tobes added a comment -

          OK thanks

          something about the decreased priority and the unassigned state?

          Show
          Eduardo Pareja Tobes added a comment - OK thanks something about the decreased priority and the unassigned state?
          Hide
          Adriaan Moors added a comment -

          Exactly.

          Show
          Adriaan Moors added a comment - Exactly.

            People

            • Assignee:
              Unassigned
              Reporter:
              Paul Phillips
            • Votes:
              8 Vote for this issue
              Watchers:
              17 Start watching this issue

              Dates

              • Created:
                Updated:

                Development