You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Require a box receiver for ssl/crypto's apply methods
`fun tag` on a primitive weakens the receiver to one that cannot read
fields, on a type that has none. It bought nothing and cost the `HashFn`
interface its implementers: a `box` method is not a subtype of a `tag`
method, so every implementer had to declare `apply` `tag` as well.
The interface has to lose `tag` before its implementers can, so all
thirteen declarations change together.
Closes#94
## Require a box receiver for ssl/crypto's apply methods
2
+
3
+
The `apply` methods on the eight one-shot hash functions (`MD4`, `MD5`, `RIPEMD160`, `SHA1`, `SHA224`, `SHA256`, `SHA384`, `SHA512`), on `ToHexString`, `RandBytes`, `HmacSha256` and `Pbkdf2Sha256`, and on the `HashFn` interface, took a `tag` receiver. They take a `box` receiver now.
4
+
5
+
Calling any of them the way you normally would — `MD5("data")`, `HmacSha256(key, message)?` — needs no change. Writing your own `HashFn` needs no change either: a `fun tag apply` still satisfies the interface, and a `fun box apply`, which did not satisfy the `tag` interface before, satisfies it now too.
6
+
7
+
The one thing that stops compiling is a reference typed `tag`, because a `box` method cannot be called through a `tag`:
0 commit comments