<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">There is a literature on
"restriction types" or "refinement types" that describes what you
are appealing to. It is most commonly used in functional
languages to describe restrictions on construction that otherwise
would not affect the representation, such as "positive integer" as
a restriction of Integer or "sorted list" as a restriction of
List. (This is a good match for functional languages because (a)
if you avoid putting a bad value into a variable in the first
place, you don't have to worry about that changing, and (b) there
is no extension, so once you restrict the value of a variable the
functions that operate on the underlying type just work on the
refined type.)<br>
<br>
Liquid Haskell (<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Liquid_Haskell">https://en.wikipedia.org/wiki/Liquid_Haskell</a>,
<a class="moz-txt-link-freetext" href="https://ucsd-progsys.github.io/liquidhaskell/">https://ucsd-progsys.github.io/liquidhaskell/</a>) is an experimental
variant of Haskell that supports refinement types, in aid of
verifiable correctness. <br>
<br>
Clojure Spec also can be thought of as a refinement type system,
allowing you to use linguistic predicates to overlay optional
constraints over an otherwise mostly-dynamically-typed system,
such as "the value associated with the map key `age` is a
non-negative integer."<br>
<br>
The bad news is that proving type safety when restrictions can
contain arbitrary predicative logic is ... hard. Liquid Haskell,
and other similar systems, often must appeal to SMT/SAT solvers to
type-check a program (which is to say that we should not be
surprised to find NP-complete problems arising as part of type
checking.)<br>
<br>
Object-oriented languages like Java would likely get to refinement
types through wrapping, which has its own set of limitations. If
the type you are refining is an interface, you're fine, but if it
is a final class (like all value classes!) you obviously have a
problem, because you can't interoperate easily between Integer and
RefinedInteger (though this problem is likely solveable for
values.)<br>
<br>
</font>
<blockquote type="cite" cite="mid:CANSoFxsnN2f5QCHQBVNJ+sc=SJpa9KNYwX36LjXvt20VHi9jxw@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>But doing that is not ideal because:</div>
<div>
<ol>
<li><span style="font-family:arial,sans-serif">This
doesn't work for primitive types </span>(e.g., a
person's age, grade point average, number of
children, etc.)</li>
<li>A wrapper class loses all of the functionality
that comes with the wrapped class. For example, I
can't say<span style="font-family:monospace">
pn1.startsWith(pn2) </span><span style="font-family:arial,sans-serif">even though
both values are essentially just </span><span style="font-family:monospace">String</span><span style="font-family:arial,sans-serif">s.</span></li>
<li>There is performance overhead</li>
</ol>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
(2) is even worse than it sounds: I can't use a WrappedString where
a String is expected, even if I manually lifted all the String
methods onto it. <br>
<br>
<blockquote type="cite" cite="mid:CANSoFxsnN2f5QCHQBVNJ+sc=SJpa9KNYwX36LjXvt20VHi9jxw@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Thoughts?</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I think the best bet for making this usable would be some mechanism
like a "view", likely only on value types, that would erase down to
the underlying wrapped type, but interpose yourself on construction,
and provided a conversion from T to RefinedT that verified the
requirement. But this is both nontrivial and presumes a lot of
stuff we don't even have yet....<br>
<br>
<br>
</body>
</html>