Scala Heaven and Hell — Michael Slinn

[Ichoran]

@eyalroth

More importantly, they should not be misguided to use them for optimizations when such optimizations are not required, which is often their case.

Why do you think that would be the case here more than elsewhere?

@eyalroth

there should be more transparency regarding Scala’s documentation in general – more examples, more measurements

I don’t understand why “transparency” is the right word to use here. What are you trying to convey by using “transparency” instead of, say, “comprehensiveness” (obviously in a different but related sentence)?

@eyalroth

I am asking that at the end, when opaques are no longer WIP, there will be some form of measurements available for the sake of transparency.

I don’t understand why “transparency” is the right word here, either, as opposed to, say, “tutorial” (again, different sentence but with similar sentiment).

@eyalroth

I would compromise for “simple” (easy to grasp) micro-benchmarks – like the ones you provided here – along with an explanation of the mechanism, and preferably at least one anecdotal real-world example of where this technique has been proven to be valuable

This is nice to aspire to, but I don’t understand why you think this needs so much attention. Or do you think everything should get this much attention, and you’re just using this as an example?

Inasmuch as the effort can be redirected at will, I’d much rather have a good deep explanation about how to use givens, how inline works, etc…

@eyalroth

I don’t know exactly what you mean by “clunky”, but I personally prefer a wrapper case class to (the currently proposed) opaque types from any perspective other than performance.

Which I would prefer depends on what I meant. If I have case class Meter(m: Double) {}, then a bunch of things are true about it, like that it’s a subclass of AnyRef, which I don’t intend to be true.

I agree that opaque types as newtypes could be better sugared in order to make them less awkward. But the current example has the virtue of simplicity: all that they do is control whether you can know what the underlying type is, and otherwise you just use standard language features.

Your suggestion doesn’t work because it assumes that all you want is for the new type to be propagated everywhere. But meters times meters are not meters, nor is Cents(i).leadingZeros a currency.