Add extension clauses #4085

odersky · 2018-03-08T14:20:41Z

This is an evolution of #4043.

Prompted by the discussion there, I made three major changes

change syntax from augment/extends to extend/implement and in a later commit to extend/:
drop labels for extends clauses
add scheme to generate stable names for extensions

adriaanm · 2018-03-08T15:22:11Z

compiler/src/dotty/tools/dotc/ast/Desugar.scala

+   *
+   *  where
+   *
+   *    <extension-name> = concatenation of all alphanumeric characters between and including `extend` and `{`,


Let's consider the impact on binary compatibility. Are there valid changes to the signature, which result in a new name, but which should not affect binary compatibility? Generally, I think it's important to give the programmer the ability to specify a name explicitly.

One easy example: exchange a fully-qualified for a relative name or vice versa.

augment List[String] {

would be binary-incompatible with

augment List[java.lang.String] {

under Martin's naming proposal.

Also, renaming a type T parameter into type U.

Plenty more like that.

Could use fully qualified names & a positional naming scheme for type params?

I think that would not be what we want. We want variation, in particular in type parameter names, so that we can avoid double definitions.

Sorry, I think what I meant to say was type patterns? The type T and type U that @sjrd mentioned above. I think you already have a double definition if you have an extension for type T and type U that share the same method name.

I think you already have a double definition if you have an extension for type T and type U that share the same method name.

No that's precisely it - you want to enable multiple extends of the same type. So you should not get a double definition if you change the parameter type.

sjrd · 2018-03-09T10:16:59Z

The blue sky sketch for extension-based typeclasses has at least two intrinsic issues:

It fundamentally creates many more wrappers at run-time, which increases memory pressure and decreases performance, compared to the existing typeclass mechanism of Scala
It does not address @OlivierBlanvillain's example with a single parameter having to honor two different typeclasses (HasArea and HasShape in that example).

and one extrinsic issue:

The purely-functional ecosystem of Scala is too large now to do a 180° turn and go back to a completely different, incompatible way of encoding typeclasses in Scala.

japgolly · 2018-03-09T12:23:57Z

docs/docs/reference/extend/instance-declarations.md

+}
+
+trait HasEql[T] {
+  def === (that: T)


Missing : Boolean

japgolly · 2018-03-09T12:24:12Z

docs/docs/reference/extend/extension-methods.md

+  def result[T](implicit er: WrappedResult[T]): T = WrappedResult.unwrap(er)
+
+  extend (type T) {
+    def ensuring[U](condition: implicit WrappedResult[T] => Boolean): T = {


[U] unused

Add `opaque` to syntax. Let it be parsed and stored/pickled as a flag.

An opaque type becomes an abstract type, with the alias stored in an OpaqueAlias annotation

maintain the link from a module class to its opaque type companion, using the same technique as for companion classes.

Higher-kinded comparisons did not account for the fact that a type constructor in a higher-kinded application could have a narrowed GADT bound.

The previous scheme, based on "magic" methods could not accommodate links from opaque types to their companion objects because there was no way to put a magic method on the opaque type. So we now use Annotations instead, which leads to some simplifications. Note: when comparing the old and new scheme I noted that the links from companion object of a value class to the value class itself broke after erasure, until they were restored in RestoreScopes. This looked unintended to me. The new scheme keeps the links unbroken throughout.

FirstTransform rewrites opaque type aliases to normal aliases, so no boxing is introduced in erasure.

It's overall simpler to just define them internally in Definitions

Make them part of the OpaqueAlias annotation. This is has two benefits - opaque types stop being companions after FirstTransform. Previously, the LinkedType annotations would persist even though the Opaque flag was reset. - we gain the freedom to implement companions between classes differently.

Use a field in ClassDenotation instead of an annotation

When computing the member denotation of a selection of a TypeRef `T`, if the normal scheme fails and `T` has GADT bounds, compute the member in the upper bound instead. This is needed to make the opaque-probability test work. Add this test, as well as some others coming from SIP 35.

The `findMember` and `underlying` methods on `TermRef` now take GADT bounds into account. This replaces the previous special case in `secectionType`. The previous case did always pass -Ycheck. Currently, the treatment is restricted to TypeRefs of opaque types. We should extend that to all GADT-bound TypeRefs. The question is how this will affect performance.

The GADT bounds set in an opaque companion also need to be established for any inlined code coming from the companion. Test case in opaque-immutable-array.scala.

The syntax is still open to discussion.

Have `type T` as an alternate for lower-case `t` identifiers as variable binders in type patterns. Over time, we will deprecate the `t` form.

Some source of nondeterminism remains in the backend.

Also, display anonymous augmentation names in nicer form.

This was fixed in one of the previous commits that affeted names

Also, drop labels.

- Use `:` instead of `implements`. Still todo: Make the `:` context constraint abstract over such instance declarations.

Allow several type aliases if they are the same.

mdedetrich · 2018-03-14T20:03:46Z

I might be a bit late to the party here as well as missing some context, but what is the case for using augment rather than implicit classes?

I noticed that that proposal advocates for deprecating implicit classes in favor of "extension methods" (or augments as the PR says), what exactly are augments gaining over implicit classes to warrant this?

What is the general impetus behind making a new augment feature, is it to replace typeclasses (in which case doesn't it make more sense to just make a language feature specifically for typeclass) or is it to make implicit classes nicer?

From the onset it seems like there isn't a coherent goal that augment is trying to achieve. I can't figure out if its just trying to rename implicit classes to augment and doing some quality of life changes or if its trying to achieve something more (such as a proper encoding of typeclasses)?

martijnhoekstra · 2018-03-15T11:43:44Z

tests/pending/pos/blueSkyExtensions.scala

+
+  extend String : Monoid {
+    static def unit = ""
+    def + (that: Int) = this ++ that


that: String surely?

odersky · 2018-03-15T16:22:35Z

Closed in favor of #4114

odersky · 2018-03-15T16:27:15Z

@mdedetrich The motivation for this work is SIP 35 and #4028. To avoid feature duplication, it would be nice if we could remove value classes once we have opaque types. Value classes have proven to be somewhat a can of worms, because of complicated restrictions and a sometimes surprising boxing model. But extension methods rely on value classes. Hence, the question: Can we find a more direct way to express extension methods?

That's the first level. The other, somewhat independent question is whether we can or should extend the scheme to do extension methods to also do instance declarations in the sense of Rust. People's opinions are so far divided on this (which means, most are against, and I am holding out :-)

adriaanm reviewed Mar 8, 2018

View reviewed changes

odersky mentioned this pull request Mar 8, 2018

Add augment clauses #4043

Closed

japgolly reviewed Mar 9, 2018

View reviewed changes

docs/docs/reference/extend/instance-declarations.md Outdated

}

trait HasEql[T] {

def === (that: T)

Copy link

Contributor

japgolly Mar 9, 2018

Choose a reason for hiding this comment

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

Missing : Boolean

japgolly reviewed Mar 9, 2018

View reviewed changes

odersky added 22 commits March 12, 2018 11:35

Add opaque types: parsing & pickling

ab9aca1

Add `opaque` to syntax. Let it be parsed and stored/pickled as a flag.

Store opaque info in annotation

5e1b0a8

An opaque type becomes an abstract type, with the alias stored in an OpaqueAlias annotation

Keep track of opaque companion links

f5ef7b8

maintain the link from a module class to its opaque type companion, using the same technique as for companion classes.

Maintain companion aliases as GADT bounds

2403e06

Test cases

f5060be

Allow for higher-kinded opaque types

b7e7ef7

Handle higher-kinded comparisons involving GADTs

a79210b

Higher-kinded comparisons did not account for the fact that a type constructor in a higher-kinded application could have a narrowed GADT bound.

Eliminate boxing for opaque types

4feb71d

FirstTransform rewrites opaque type aliases to normal aliases, so no boxing is introduced in erasure.

Make OpaqueAlias and LinkedType special classes

1f985da

It's overall simpler to just define them internally in Definitions

Make implicit scope include companion objects of opaque types

3fb11d2

Add reference documentation

f9b141b

Fix test

599b408

Fix indentation

cdc5e54

Replace annotation extractor with access methods

1d03fc0

Simplify companion scheme

4293432

Use a field in ClassDenotation instead of an annotation

add test

8ac08cc

Bump minor Tasty version

c6bb46f

Extend opaque companion context to inlined code

5de563b

The GADT bounds set in an opaque companion also need to be established for any inlined code coming from the companion. Test case in opaque-immutable-array.scala.

odersky force-pushed the add-extend branch from b2b11b4 to 9d4e528 Compare March 12, 2018 10:38

odersky added 2 commits March 14, 2018 15:42

Add augment clauses

f6dffe4

The syntax is still open to discussion.

Allow for type id in type patterns

971e385

Have `type T` as an alternate for lower-case `t` identifiers as variable binders in type patterns. Over time, we will deprecate the `t` form.

odersky and others added 19 commits March 14, 2018 15:42

Implement extension methods as implicit value classes

f8b661d

Partially fix idempotency of static method order

b90acc1

Some source of nondeterminism remains in the backend.

Allow labels naming an augment

55405d8

Use semantic names for augmentations

d4f50df

Also, display anonymous augmentation names in nicer form.

Add regression test for idempotency issue on static methods

823ba95

This was fixed in one of the previous commits that affeted names

Add docs for extension methods

90ec0ee

More docs for augmentations

0b0c2e0

Remove duplicate test

5297996

Fix typos

1c55e04

Change syntax from augment/extends to extend/implements

1e4b2a1

Also, drop labels.

Fix test and error reporting

ff65a2b

Require implemented types to be traits

53298ce

Another test - magnet pattern

19d12d9

Change syntax of instance declarations

f8bd21a

- Use `:` instead of `implements`. Still todo: Make the `:` context constraint abstract over such instance declarations.

A blue sky sketch how one could possibly evolve extends clauses

b757ba9

Fix test

23c863e

Fix typos

420a79d

More blue sky variants

09aa5d2

Some small updates and variants to blySkyExtensions

51bff8d

odersky added the stat:wip label Mar 14, 2018

Relax restriction about type overrides

cfc9058

Allow several type aliases if they are the same.

More escaping of "extension"

f65f8b3

odersky force-pushed the add-extend branch from 9d4e528 to f65f8b3 Compare March 15, 2018 09:48

martijnhoekstra reviewed Mar 15, 2018

View reviewed changes

odersky mentioned this pull request Mar 15, 2018

Add named extensions #4114

Closed

odersky closed this Mar 15, 2018

liufengyun mentioned this pull request Jul 5, 2019

Change extension method syntax. #6760

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add extension clauses #4085

Add extension clauses #4085

odersky commented Mar 8, 2018 •

edited

Loading

adriaanm Mar 8, 2018

sjrd Mar 8, 2018

DavidGregory084 Mar 8, 2018

odersky Mar 8, 2018

DavidGregory084 Mar 8, 2018

odersky Mar 8, 2018

sjrd commented Mar 9, 2018

japgolly Mar 9, 2018

japgolly Mar 9, 2018

mdedetrich commented Mar 14, 2018 •

edited

Loading

martijnhoekstra Mar 15, 2018

odersky commented Mar 15, 2018

odersky commented Mar 15, 2018

Add extension clauses #4085

Add extension clauses #4085

Conversation

odersky commented Mar 8, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sjrd commented Mar 9, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mdedetrich commented Mar 14, 2018 • edited Loading

Choose a reason for hiding this comment

odersky commented Mar 15, 2018

odersky commented Mar 15, 2018

odersky commented Mar 8, 2018 •

edited

Loading

mdedetrich commented Mar 14, 2018 •

edited

Loading