Thoughts on peeling and readability

[Timo Kinnunen]

Field layout and bit fiddling isn’t exactly what I was thinking. Rather I was thinking something like Float.floatToRawIntBits() and Double.doubleToRawLongBits(), but without having to know about the types Float and Double or how many bits are in their raw bits. So something like this syntax:

	static <any T> T nextUp (T value) {
		<?missing type?> rawBits = T.toRawBits(value);
		T nextValue = T.fromRawBits(rawBits + 1);
		return nextValue;
	}

This should fit in Valhalla reasonably well, as it is just a generalization of T.default with its complement operation included. And as it is, all of the problems you listed already apply to T.default. For example, a value type with one long field: If the long value in the field is a handle pointing to a memory-mapped buffer then any use of a default value of such a type could cause a crash. Which can include asking a properly constructed value if it is equal to any of the values in an array you have.




-- 
Have a nice day, 
Timo

Sent from Mail for Windows 10



From: Brian Goetz
Sent: Saturday, December 12, 2015 18:21
To: Timo Kinnunen;Maurizio Cimadamore;Paul Benedict;valhalla-dev at openjdk.java.net
Subject: Re: Thoughts on peeling and readability


Precise layout and bit control of values are anti-goals of Valhalla, so 
we're not really exploring this direction at this time.

The problem with approaches like the one you suggest is they fall apart 
as soon as you leave the realm of "primitives modeled as values."  What 
about values that have refs in them?  What about values whose 
representations are private?  Their implementation is supposed to be in 
sole control of their representation.  This runs contrary to the "codes 
like a class" dictum.






On 12/12/2015 4:43 AM, Timo Kinnunen wrote:
> Hi,
>
> One thing that I don’t remember seeing is any syntax for constructing arbitrary values in generic code without having to know about the precise field layouts and what the meaning of such fields is. Something like T.default but for values other than 0. Perhaps T.default(12345) or some such?
>
> Or maybe this is slated to go with bytecode type specialization… What sort of syntax is envisioned to be driving that anyways?
>
>
>
>
>