Details

      Description

      These are particularly bad because they are runtime failures with no obvious way to know what will fail. Example.

      scala> List(1,2,3).view.dropRight(1)
      java.lang.UnsupportedOperationException: SeqView(...).newBuilder
      	at scala.collection.TraversableViewLike$$class.newBuilder(TraversableViewLike.scala:53)
      	at scala.collection.SeqLike$$$$anon$$2.newBuilder(SeqLike.scala:978)
      	at scala.collection.IterableLike$$class.dropRight(IterableLike.scala:176)
      	at scala.collection.SeqLike$$$$anon$$2.dropRight(SeqLike.scala:978)
      	at .<init>(<console>:8)
      	at .<clinit>(<console>)
      	at .<init>(<console>:11)
      	at .<clinit>(<console>)
      	at $$export(<console>)
      

      It would make a lot more sense to me if views implemented an abstract interface (and thus the compiler would tell us what methods aren't covered) than having them override all kinds of inherited implementations, with runtime failure for methods which are missed or otherwise elude the concrete barriers.

      (Get it, concrete barriers? That is gold.)

        Activity

        Hide
        Jason Zaugg added a comment -

        Another example from SI-7610

        scala> a.view.map { _+1}.filter{_%2==0}.distinct
        java.lang.UnsupportedOperationException: SeqViewMF(...).newBuilder
        at scala.collection.TraversableViewLike$class.newBuilder(TraversableViewLik
        
        Show
        Jason Zaugg added a comment - Another example from SI-7610 scala> a.view.map { _+1}.filter{_%2==0}.distinct java.lang.UnsupportedOperationException: SeqViewMF(...).newBuilder at scala.collection.TraversableViewLike$class.newBuilder(TraversableViewLik
        Hide
        Edmondo Porcu added a comment -

        I've hit the problem with the SeqViewLike. all the methods of SeqLike not overriden in the trait are forwarded back to the SeqLike trait, and try to use the standard builder. From what I could see in the code I think this could be case for other collection as well.

        I wonder if it would not be safer for the community to deprecate or remove views and favour iterator style in one of the next releases. This is a small non breaking change that will immediately force user to run away from views.

        Show
        Edmondo Porcu added a comment - I've hit the problem with the SeqViewLike. all the methods of SeqLike not overriden in the trait are forwarded back to the SeqLike trait, and try to use the standard builder. From what I could see in the code I think this could be case for other collection as well. I wonder if it would not be safer for the community to deprecate or remove views and favour iterator style in one of the next releases. This is a small non breaking change that will immediately force user to run away from views.
        Hide
        Adriaan Moors added a comment -

        Unassigning and rescheduling to M6 as previous deadline was missed.

        Show
        Adriaan Moors added a comment - Unassigning and rescheduling to M6 as previous deadline was missed.
        Hide
        Jason Zaugg added a comment -

        Discussion of a solution to identify current and future view gaps: https://github.com/scala/scala/pull/3191#issuecomment-29182578

        Show
        Jason Zaugg added a comment - Discussion of a solution to identify current and future view gaps: https://github.com/scala/scala/pull/3191#issuecomment-29182578
        Show
        Jason Zaugg added a comment - https://github.com/scala/scala/pull/3192

          People

          • Assignee:
            Jason Zaugg
            Reporter:
            Paul Phillips
            TracCC:
            Paul Phillips, Seth Tisue
          • Votes:
            13 Vote for this issue
            Watchers:
            17 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development