This repository was archived by the owner on Sep 1, 2020. It is now read-only.
Add support for literal Byte and Short values. #12
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit reserves the [zZ] and [sS] suffixes for Byte and Short literals, respectively. These work exactly like Long literals, which were already denoted with [lL]. For example, you can say: val zero = 0Z val bytes = List(23Z, 23Z, 0Z, 0Z, 111Z, -54Z, 19Z, 17Z) This commit does not permit literal unsigned bytes, so 255Z and 0xffZ are not legal. The choice of Z may seem strange, but B will not work for hex constants (0x10B would be ambiguous) so Z seemed like a good choice.
|
As the commit's author, I say 👍 |
|
Someone please fix my ignorance, but doesn't the |
|
@djspiewak Did you see the commit message? |
|
What? Reading justifications?! Pshshshshshsh. :-) That does make sense; thanks. |
puffnfresh
added a commit
that referenced
this pull request
Sep 5, 2014
Add support for literal Byte and Short values.
|
@puffnfresh Weren't we waiting for CI etc. before merging? |
|
@Blaisorblade this is a commit which we tested pretty well a few months ago. I'll definitely be waiting for CI before doing much more. |
aloiscochard
pushed a commit
to aloiscochard/scala
that referenced
this pull request
Sep 5, 2014
Automate release: settings for dependency versions.
|
Alright, sorry for the noise! |
|
Did the Z suffix come out of some searching around or is it (pseudo) random? For example, here is what #fsharp has and they do cover a lot of cases http://msdn.microsoft.com/en-us/library/dd233193.aspx. What does Haskell say on this? Other languages? |
|
We chose it because A-F aren't available, and because it's associated with the Integers in math (even though we're using it to represent a tiny subset of them). http://en.wikipedia.org/wiki/Integer |
milessabin
pushed a commit
that referenced
this pull request
Oct 24, 2016
Top level modules in Scala currently desugar as:
```
class C; object O extends C { toString }
```
```
public final class O$ extends C {
public static final O$ MODULE$;
public static {};
Code:
0: new #2 // class O$
3: invokespecial #12 // Method "<init>":()V
6: return
private O$();
Code:
0: aload_0
1: invokespecial #13 // Method C."<init>":()V
4: aload_0
5: putstatic #15 // Field MODULE$:LO$;
8: aload_0
9: invokevirtual #21 // Method java/lang/Object.toString:()Ljava/lang/String;
12: pop
13: return
}
```
The static initalizer `<clinit>` calls the constructor `<init>`, which
invokes superclass constructor, assigns `MODULE$= this`, and then runs
the remainder of the object's constructor (`toString` in the example
above.)
It turns out that this relies on a bug in the JVM's verifier: assignment to a
static final must occur lexically within the <clinit>, not from within `<init>`
(even if the latter is happens to be called by the former).
I'd like to move the assignment to <clinit> but that would
change behaviour of "benign" cyclic references between modules.
Example:
```
package p1; class CC { def foo = O.bar}; object O {new CC().foo; def bar = println(1)};
// Exiting paste mode, now interpreting.
scala> p1.O
1
```
This relies on the way that we assign MODULE$ field after the super class constructors
are finished, but before the rest of the module constructor is called.
Instead, this commit removes the ACC_FINAL bit from the field. It actually wasn't
behaving as final at all, precisely the issue that the stricter verifier
now alerts us to.
```
scala> :paste -raw
// Entering paste mode (ctrl-D to finish)
package p1; object O
// Exiting paste mode, now interpreting.
scala> val O1 = p1.O
O1: p1.O.type = p1.O$@ee7d9f1
scala> scala.reflect.ensureAccessible(p1.O.getClass.getDeclaredConstructor()).newInstance()
res0: p1.O.type = p1.O$@64cee07
scala> O1 eq p1.O
res1: Boolean = false
```
We will still achieve safe publication of the assignment to other threads
by virtue of the fact that `<clinit>` is executed within the scope of
an initlization lock, as specified by:
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.5
Fixes scala/scala-dev#SD-194
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit reserves the [zZ] and [sS] suffixes for Byte and
Short literals, respectively. These work exactly like Long
literals, which were already denoted with [lL].
For example, you can say:
This commit does not permit literal unsigned bytes, so 255Z and
0xffZ are not legal.
The choice of Z may seem strange, but B will not work for
hex constants (0x10B would be ambiguous) so Z seemed like a
good choice.