Re: [swift-evolution] extension of AnyObject

[John McCall via swift-evolution]

> On Dec 29, 2017, at 11:21 PM, Kenny Leung via swift-evolution 
>  wrote:
> 
> Hi All.
> 
> I just discovered that you can’t write an extension on AnyObject. What’s the 
> reasoning behind this?
> 
> I’m trying to write my own version of KeyValueObserving, and it would be 
> really nice to be able to write
> 
>self.observe(someObject, keyPath) {
>blah de blah
>}
> 
> from anywhere.

The rationale is that AnyObject is a somewhat "structural" protocol, one that's 
really just "this is a class type", which means that extensions on it would 
become a way to add methods to a largely-unresticted set of types.  We've been 
reluctant to allow that for the same reason that we've been reluctant to allow 
extensions on Any.  One such reason that's particularly significant to me is 
that it feels like that would be an ability that would be quickly abused, so 
that the namespace of methods on Any/AnyObject would quickly become very 
crowded, downgrading the experience of code-completion, compiler diagnostics, 
and so on.

John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[John McCall via swift-evolution]

> On Dec 31, 2017, at 1:21 PM, Cheyo Jimenez  wrote:
> 
> 
> 
> On Dec 31, 2017, at 8:59 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
>>> On 21 Dec 2017, at 03:32, John McCall wrote:
>>> 
> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote:
> 
> On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote:
> 
>   • What is your evaluation of the proposal?
 
 I am pleased with the broad strokes of this design. I have quibbles with 
 three areas:
 
 1. The `@exhaustive` attribute may be confusing because the term doesn't 
 suggest versioning. My best alternative suggestion is `@frozen`, which 
 matches existing programming terminology: something that has been frozen 
 will not be changed in the future.
>>> 
>>> I rather like @frozen.  We could use that across language features, so that 
>>> we don't end up with a keyword per kind of declaration.
>> 
>> Could this also be used on functions to make them inlinable?
>> i.e. The body of the function has been frozen.
>> 
>> ```
>> @frozen
>> public func a()
>> 
>> @available(*, frozen)
>> public func b()
>> 
>> @available(swift, introduced: 4.1, frozen: 5.0)
>> public func c()
>> 
>> ```
> 
> My understanding is that frozen / exhaustible is guaranteed by the compiler 
> while inlineable is more of a strong suggestion to the compiler. It would be 
> confusing to use the same word for both.

Well, this is both true, and false, and true again.

It's true that frozen/inlineable on a function leaves the choice of whether to 
actually perform inlining (or other interprocedural optimizations like 
specialization) up to the compiler, whereas the impact of frozen on a type has 
a direct and reliably-observable impact in the sense of lifting certain 
semantic restrictions.

But from another perspective, the meaning of the attribute to the implementor 
is the same in both cases: it means that the implementation is the same across 
versions.  frozen on a type means that the basic storage structure of the type 
won't change (i.e. it has exactly the same stored properties/cases), and frozen 
on a function means that the behavior of the function won't change.

But then again, while we can reliably check the correctness of frozen on a 
type, we can't really check that for a function.  We can check 
frozen-correctness on a type because we don't mind forbidding non-trivial 
changes to the storage structure: i.e. the set of stored properties/cases (and 
their types) have to remain exactly the same, meaning you can't even do 
"obviously equivalent" changes like combining two stored properties into a 
single property of tuple type.  But we don't want to be that strict with 
functions because we do want to allow some non-trivial differences: it's 
frequently possible to improve the implementation of a function without 
changing its behavior, and we don't want to make that impossible, but we also 
don't really want to get into the business of requiring library authors to 
prove the semantic equivalence of two different function bodies.  That means we 
just have to take implementors at their word that using the new function body 
instead of the old isn't too annoying a difference.  I know Joe Groff has 
proposed in the past that we use a somewhat different semantic model for 
inlineable functions, one that promises that we use the newest available 
functionality, and I think there's some merit to that.

To me, the important questions around keyword choice are:
  - whether the operations feel sufficiently different that using the same 
keyword is going to feel awkward;
  - whether we might be preventing useful expressiveness by using the same 
keyword (the thing that occurs to me is that having a separate attribute for 
inlineable might let us easily mass-annotate an extension, which seems like a 
common use-case); and
  - whether we can get community agreement about it, which might seem "meta", 
but sometimes one must pick one's battles.

John.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Happy new year Swift community.

[Goffredo Marocchi via swift-evolution]

Happy new year everybody :)!

Sent from my iPhone

> On 31 Dec 2017, at 23:43, David Hart via swift-evolution 
>  wrote:
> 
> Thank you very much and happy new Swift year to everybody.
> 
>> On 1 Jan 2018, at 00:42, Adrian Zubarev via swift-evolution 
>>  wrote:
>> 
>> Well some of you guys have to wait a little longer, but I can already wish 
>> everyone a happy new year from Germany.  
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Happy new year Swift community.

[David Hart via swift-evolution]

Thank you very much and happy new Swift year to everybody.

> On 1 Jan 2018, at 00:42, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Well some of you guys have to wait a little longer, but I can already wish 
> everyone a happy new year from Germany.  
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Happy new year Swift community.

[Adrian Zubarev via swift-evolution]

Well some of you guys have to wait a little longer, but I can already wish 
everyone a happy new year from Germany.   

--  
Adrian Zubarev
Sent with Airmail ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Matthew Johnson via swift-evolution]

I have been busy over the holidays and have been considering the arguments in 
this thread so my review is late in coming.
> What is your evaluation of the proposal?
> 
I agree that we need a solution to the problem described.  I also agree that 
non-exhaustive is most in keeping with the overall design of Swift at module 
boundaries.  However, I believe this proposal should be modified before being 
accepted

My primary concern (shard with many others) is that this proposal takes away an 
important tool of exhaustiveness checking in cases where we need to switch over 
an enum vended by a library which was not declared exhaustive.  

This is likely to be a relatively rare need mostly encountered by 3rd party 
libraries but it will happen.  When it does happen it would be really 
unfortunate to be forced to use a `default` clause rather than something like a 
`future` clause which will produce an error when compiled against an SDK where 
the enum includes cases that are not covered.  I can imagine cases where this 
catch-all case would need to do something other than abort the program so I do 
not like the `switch!` suggestion that has been discussed.  The programmer 
should still be responsible for determining the behavior of unknown cases.

I find the argument of untestable code to be completely unconvincing.  As has 
been noted several times in this thread, when all known cases are covered in a 
switch statement the code is equally untestable whether the “other" pattern is 
spelled `default` or `future`.  There has been some discussion of finding a way 
for the compiler to support an extra test-only value somehow.  A tool like this 
could be quite useful regardless of how the “other” pattern is spelled but the 
presence or absence of this tool should not influence the decision to include 
“future” or not.

While library authors have a legitimate need to reserve the right to introduce 
new cases for some enums this need can be met without taking away a useful tool 
for generating static compiler errors when code does not align with intent (in 
this case, the intent being to cover all known cases).  Switch statements 
working with these kinds of enums should be required to cover unknown cases but 
should be able to do so while still being statically checked with regards to 
known cases.  

People are going to write these kinds of switch statements whether the language 
helps them out or not.  Instead of taking a moral standpoint that says “that is 
bad, don’t do it” the language should continue to provide assistance to the 
degree it can.  If the core team remains unconvinced about use cases for these 
kinds of "pseudo-exhaustive” switches I suggest a brief extension to the review 
with a specific request for example use cases.  I believe several good examples 
could be quickly identified in existing open source libraries.

A secondary concern I have is the @exhaustive keyword itself.  I strongly 
believe Swift will be better suited by a more general keyword that is also 
applicable in other contexts.  

I authored earlier discussions about how exhaustiveness could fit into the 
access control system.  This is discussed as an alternative under “closed” and 
“open”.  I think “closed” as a “greater than public” availability with respect 
to switch statements is perfectly sensible.  In this design the access control 
hierarchy would have two branches in different directions that are both 
"greater than public”.  This direction had some proponents but didn’t appear to 
gain traction with the core team.  In case the core team discusses this option 
I do still prefer it.

Another direction that has been discussed in this thread is to use a keyword 
that is shared with fixed layout structs.  Both of these feel like better 
options than a special case, enum-only attribute.  On the other hand, this is a 
relatively minor concern.
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
Yes.
> Does this proposal fit well with the feel and direction of Swift?
> 
For the most part.  However, it does introduce a special case attribute 
specifically for enums.  I would prefer if we try to avoid that and believe it 
is in keeping with the direction of Swift to try and avoid these.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
I have not worked with a language that supported both exhaustive and 
non-exhaustive enums.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
In-depth study of the proposal and all of the threads on the list.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Cheyo Jimenez via swift-evolution]

On Dec 31, 2017, at 8:59 AM, Ben Rimmington via swift-evolution 
 wrote:

>> On 21 Dec 2017, at 03:32, John McCall wrote:
>> 
 On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote:
 
 On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote:
 
• What is your evaluation of the proposal?
>>> 
>>> I am pleased with the broad strokes of this design. I have quibbles with 
>>> three areas:
>>> 
>>> 1. The `@exhaustive` attribute may be confusing because the term doesn't 
>>> suggest versioning. My best alternative suggestion is `@frozen`, which 
>>> matches existing programming terminology: something that has been frozen 
>>> will not be changed in the future.
>> 
>> I rather like @frozen.  We could use that across language features, so that 
>> we don't end up with a keyword per kind of declaration.
> 
> Could this also be used on functions to make them inlinable?
> i.e. The body of the function has been frozen.
> 
> ```
> @frozen
> public func a()
> 
> @available(*, frozen)
> public func b()
> 
> @available(swift, introduced: 4.1, frozen: 5.0)
> public func c()
> 
> ```

My understanding is that frozen / exhaustible is guaranteed by the compiler 
while inlineable is more of a strong suggestion to the compiler. It would be 
confusing to use the same word for both. 
> 
> 
> 
> 
> -- Ben
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

[Karl Wagner via swift-evolution]

> On 31. Dec 2017, at 00:12, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Sorry for the delay. I've just updated the proposal text to incorporate 
> various changes, some contributed by others.
> 
> https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/-derived-collection-of-enum-cases.md
>  
> 
> 
> Robert's implementation 
>  is 
> a good start, but will need to be updated to match the naming choice in the 
> final proposal, and to use associatedtype.


Looks good, but I have two questions:

1) What is the exact semantic meaning of ValueEnumerable? Does it somehow imply 
an enum? Or is it simply an abstraction for any type with a “fixed, finite set 
of [values]”?

I ask because the standard library includes some non-enum types which also fit 
that definition: namely Bool, Unicode characters, and the various integer 
types. Would it make sense for those types to also conform (regardless if its 
part of the proposal; I’m asking if you would consider that a “misuse” of the 
protocol)?.

2) Is the order of values in the Collection generally meaningful, or not? If 
not, would it be reasonable for types which conform to Comparable to always 
return a sorted Collection? Or should we manually sort it with 
“MyEnum.allValues.sorted()”?

- Karl

> 
> On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher 
> > wrote:
> Has this stalled out again? I would like to help with the proposal and even 
> attempt implementation. 
> 
> I also need to catch up on the resilient discussion regarding enum case 
> ordering. 
> 
> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution 
> > wrote:
> 
>> 
>> 
>> Jacob Bandes-Storch
>> 
>> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon > > wrote:
>>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu >> > wrote:
>>> 
>>> 1. It must be possible to easily access the count of values, and to access 
>>> any particular value using contiguous `Int` indices. This could be achieved 
>>> either by directly accessing elements in the list of values through an Int 
>>> subscript, or by constructing an Array from the list of values.
>>> 
>>> 2. It must be possible to control the order of values in the list of 
>>> values, either by using source order or through some other simple, 
>>> straightforward mechanism.
>>>  
>>> OK, first of all, nowhere in the proposal text are these requirements 
>>> stated as part of the use case. You're free to put forward new use cases, 
>>> but here I am trying to design the most elegant way to fulfill a stated 
>>> need and you're telling me that it's something other than what's written.
>> 
>> Honestly, re-reading the proposal, it never cites a fully-formed use case. 
>> Instead, it cites several blog posts, Stack Overflow questions, and small 
>> code samples without digging in to the underlying reasons why developers are 
>> doing what they're doing. Most of the people discussing it so far seem to 
>> have had a tacit understanding that we wanted roughly Array-like access, but 
>> we haven't explicitly dug into which properties of an Array are important.
>> 
>> (If anyone involved feels like they had a different understanding of the use 
>> case, please speak up.)
>> 
>> I think this is a place where the proposal can be improved, and I'm willing 
>> to do some writing to improve it.
>> 
>> For the record, I would be happy to add co-authors (or even relinquish 
>> authorship entirely—I don't really care whose name is on this, it just needs 
>> to happen!) if you or anyone else has improved wording, motivation, 
>> justification, etc. to contribute.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

[Félix Cloutier via swift-evolution]

In addition to what Chris said: enums imported from C and @objc enums can both 
have extensions and conform to protocols, so IMO it should be legal to write 
something like `extension Foundation.ComparisonResult: ValueEnumerable {}`.

Félix

> Le 30 déc. 2017 à 19:00, Jacob Bandes-Storch via swift-evolution 
>  a écrit :
> 
> Re-reading this thread and thinking about it more, I think I agree :)  
> Updating again...
> 
> On Sat, Dec 30, 2017 at 3:44 PM, Chris Lattner  > wrote:
> On Dec 30, 2017, at 3:12 PM, Jacob Bandes-Storch via swift-evolution 
> > wrote:
>> Sorry for the delay. I've just updated the proposal text to incorporate 
>> various changes, some contributed by others.
>> 
>> https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/-derived-collection-of-enum-cases.md
>>  
>> 
> I would really love to see this happen.  I did a pass over the proposal, I 
> strong suggest that you get Joe Groff’s input on this, because he has some 
> opinions as well.
> 
> IMO, the proposal looks really great except for one thing:   In "proposed 
> solution”, I think it is very important that conformance to ValueEnumerable 
> be explicitly requested in the code.  Specifically:
> 
> enum Ma { case 马, 吗, 妈, 码, 骂, 麻, ,  }
> Ma.allValues   // error.
> 
> enum Ma : ValueEnumerable { case 马, 吗, 妈, 码, 骂, 麻, ,  }
> Ma.allValues   // works!
> 
> 
> This is for two reasons:
> 1) Consistency with other similar features in Swift.  Types are not hashable 
> just because their members could be.  This is because we want people to think 
> about and explicitly opt into API features like this.
> 2) To align with our resilience design.  An enum with no value-associated 
> cases today could acquire them in the future, and doing so would implicitly 
> remove this conformance.  This would be surprising and bad.
> 
> Thanks for pushing this forward!
> 
> -Chris
> 
> 
> 
> 
> 
> 
>> Robert's implementation 
>>  
>> is a good start, but will need to be updated to match the naming choice in 
>> the final proposal, and to use associatedtype.
>> 
>> On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher 
>> > wrote:
>> Has this stalled out again? I would like to help with the proposal and even 
>> attempt implementation. 
>> 
>> I also need to catch up on the resilient discussion regarding enum case 
>> ordering. 
>> 
>> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
>>> Jacob Bandes-Storch
>>> 
>>> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon >> > wrote:
 On Nov 14, 2017, at 5:21 PM, Xiaodi Wu > wrote:
 
 1. It must be possible to easily access the count of values, and to access 
 any particular value using contiguous `Int` indices. This could be 
 achieved either by directly accessing elements in the list of values 
 through an Int subscript, or by constructing an Array from the list of 
 values.
 
 2. It must be possible to control the order of values in the list of 
 values, either by using source order or through some other simple, 
 straightforward mechanism.
  
 OK, first of all, nowhere in the proposal text are these requirements 
 stated as part of the use case. You're free to put forward new use cases, 
 but here I am trying to design the most elegant way to fulfill a stated 
 need and you're telling me that it's something other than what's written.
>>> 
>>> Honestly, re-reading the proposal, it never cites a fully-formed use case. 
>>> Instead, it cites several blog posts, Stack Overflow questions, and small 
>>> code samples without digging in to the underlying reasons why developers 
>>> are doing what they're doing. Most of the people discussing it so far seem 
>>> to have had a tacit understanding that we wanted roughly Array-like access, 
>>> but we haven't explicitly dug into which properties of an Array are 
>>> important.
>>> 
>>> (If anyone involved feels like they had a different understanding of the 
>>> use case, please speak up.)
>>> 
>>> I think this is a place where the proposal can be improved, and I'm willing 
>>> to do some writing to improve it.
>>> 
>>> For the record, I would be happy to add co-authors (or even relinquish 
>>> authorship entirely—I don't really care whose name is on this, it just 
>>> needs to happen!) if you or anyone else has improved wording, motivation, 
>>> justification, etc. to 

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Ben Rimmington via swift-evolution]

> On 21 Dec 2017, at 03:32, John McCall wrote:
> 
>> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon wrote:
>> 
>>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote:
>>> 
>>> • What is your evaluation of the proposal?
>> 
>> I am pleased with the broad strokes of this design. I have quibbles with 
>> three areas:
>> 
>> 1. The `@exhaustive` attribute may be confusing because the term doesn't 
>> suggest versioning. My best alternative suggestion is `@frozen`, which 
>> matches existing programming terminology: something that has been frozen 
>> will not be changed in the future.
> 
> I rather like @frozen.  We could use that across language features, so that 
> we don't end up with a keyword per kind of declaration.

Could this also be used on functions to make them inlinable?
i.e. The body of the function has been frozen.

```
@frozen
public func a()

@available(*, frozen)
public func b()

@available(swift, introduced: 4.1, frozen: 5.0)
public func c()

```




-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pre-Pitch] Another go at "strong typedef" / alternative types / reduced-state types

[Daryle Walker via swift-evolution]

(Warning: rambling stream-of-conscious mode while slightly tired)

The names of new keywords and identifiers are subject to bike-shedding.

1. Set-up Protocols

protocol HardRawRepresentable: RawRepresentable {
init(rawValue: RawValue)
}

Just like RawRepresentable, but the initializer has to be non-failable (“init?” 
and “init!” are no longer options).

protocol RawProcessable: RawRepresentable {
mutating func withMutableRawValue(_ body: (inout RawValue) throws -> R ) 
rethrows -> R
}

Maybe someone will find a use for this outside of type-copies.

2. Type-copy Type Syntax

A “typecopy” puns another value type, either nominal (structures, enumerations, 
or other type-copies) or structural (tuples, and fixed-size arrays if added). I 
guess it’d be implemented like a structure with a single instance-level stored 
property or an enumeration without indirect and/or associated values. Unlike a 
type alias, a type-copy is considered distinct from its underlying type and 
conversions have to be explicit casts. It has no operations by default besides 
copying (which every type has); adaptations of the underlying type’s interface 
have to be explicitly copied, and can be selective.

typecopy NewType: SPECIAL-ATTRIBUTES UnderlyingType, DesiredProtocols {
// Anything other nominal types have, except enumeration cases and 
instance-level stored properties.
// Also have new syntax to copy parts of the underlying type’s interface.
}

All type-copies conform to RawProcessible; the particulars depend on the 
special attributes (which are conditional keywords).

The initializer that satisfies RawRepresentable is the type’s designated 
initializer. It cannot be defined by the user; only secretly by the system; 
it’s an error to introduce one anyway in the primary definition block, an 
extension, or a default implementation from an added protocol. Any 
user-declared initializer that doesn’t forward to another user-declared 
initializer must forward to the designated initializer.

2a. No Special Attributes

The type must define a method called

static func #map(rawValue: RawValue) -> RawValue?

I’m using “#map” as the name so we don’t take out any more identifiers from the 
user. (The existing ones, “self,” “init,” “super,” and “Self,” were already 
done by Objective-C.) The function must be pure relative to the input; it can 
call non-impurities, like “print,” but the return value must depend only on the 
argument and not any global state. The user cannot call this function, only the 
system (but it can be implemented with regular, accessible functions you do 
write); let’s call this accessibility “reallyprivate". The designated 
initializer is in the “init?” form and calls this special method for the 
initial state.

The underlying state is accessed with this stored property:

pp reallyprivate(set) var rawValue: RawValue

where “pp” is the type’s accessibility level.

The implementation of “withMutableRawValue” copies “rawValue” to a mutable 
copy, calls the closure passing that copy, then assigns “Self(rawValue: 
newCopy)!” to self, causing a runtime error if the initialization part fails.

2b. The “injective” Attribute

This means that the mapping function must be a total function, and not partial:

static func #map(rawValue: RawValue) -> RawValue

Every legal state of RawValue is usable in the new type. (It may not be stored 
in the new type; the mapping function can be surjective.) These type-copies 
also conform to HardRawRepresentable.

The main external effect of this attribute is that downcasts from the 
underlying type to the new type use unconditional-“as”. (Downcasts and 
cross-casts from a type that shares the same implementation type also use 
unconditional-as if all the downcast phase links also use unconditional-as.)

2c. The “selfIdeal” Attribute

This means that all approved input states map to themselves in the storage 
state, this changes the required secret method to:

static func #approve(rawValue: RawValue) -> Bool

It effectively acts like case [2a] where “#map” calls “#approve” and returns 
either the input for TRUE or NIL for FALSE.

The main external effect of this attribute is that downcasts (and the downcast 
phase of cross-casts) can be trivially done with direct type punning, assuming 
all the “#approve” calls AND to TRUE, instead of possibly longer “#map” calls.

2d. Using “injective” and “selfIdeal” together

This combination means every input state is accepted, and map to themselves; 
this is exactly a “strong typedef”. Such types conform to HardRawRepresentable. 
There is no special method required; the value is just copied in without 
wasting time calling the bijective identity function. And the “rawValue” 
property has its “set” just as public as its “get”. (Technically, you can 
change “rawValue” by setting it directly or calling “withMutableRawValue”.)

3. Why would I want this?

The original inspiration was my first fixed-size array ideas have a simple 
structural