[swift-evolution] Pure functions

[Daryle Walker via swift-evolution]

Should we add support for recognition of pure functions?  These functions don’t 
refer to any global state; their return values / outgoing in-out parameter 
states depend solely on the incoming argument values.  I know at least the D 
programming language acknowledges them.

- Should they be marked with a “pure” attribute?
- How much checking should the complier do on code for purity violations?
- Should purity be a potential requirement on protocol methods?
- What kinds of optimizations are possible?
- What default built-in or standard library support should be pure as an 
initial set to build your own pure functions?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] No disjunctions in type constraints: why?

[Daryle Walker via swift-evolution]

>From 
>.

Maybe I’m not up on my Type Theory, but why should type constraint disjunctions 
be banned?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___
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 

[swift-evolution] [Potential Idea] How to indicate a trivial strong-typedef?

[Daryle Walker via swift-evolution]

Here’s a quick review of a strong-“typedef” idea I’ve mentioned here:

typecopy MyNewType: OriginalValueType, AnyProtocolsIWant {
// Direct member declarations
// “publish MemberFromOriginalType” for all overloads (or the singular item for 
non-functions)
// “publish MemberWithSignatureFromOriginalType” to pick out one subset of 
overloads
// “publish MemberWithSignatureAndParameterNamesFromOriginalType” to pick out 
one overload
// “publish ProtocolThatOriginalTypeConfromsTo"
}

(The name “typecopy” is changed from “alter”.)

All type-copies automatically conform to the new system AnyTypeCopy protocol, 
which derives from RawRepresentable. It just adds the “CoreRawValue” type. This 
type alias matches RawValue if that is a non-typecopy; otherwise it aliases 
that type copy’s CoreRawValue type. AnyTypeCopy cannot be added to non-typecopy 
types. Any protocol that derives from it can only be applied to typecopy types. 
 Type-copies are value types, and can only shadow structures, enumerations, 
other type-copies, tuples, and fixed-size arrays (if added).

The initializer used to conform to RawRepresentable is the type’s designated 
initializer. It’s the only one that can access “super.” Any other initializers 
added must be convenience and reference the designated one. (Published 
initializers are considered convenience.) The designated initializer can be 
fail-able to model subtypes. The designated initializer can pass on an altered 
value to model quotient types (or any other crazy mapping scheme); including 
being fail-able too (i.e. a quotient type of a subtype).

Of course, the designated initializer could do neither changes nor filtering:

typecopy MyResourceID: Int16, Hashable {
init(rawValue: RawValue) { super = rawValue }
publish Equatable
var hashValue: Int { get {return rawValue.hashValue & 0x01} }
}

Since every valid state of Int16 is also a valid state of MyResourceID, and 
without remapping, this type-copy is a trivial copy of its source. Besides 
downcasts (and cross-casts) never being fail-able, all sorts of other 
type-punning and related optimizations should be possible. (Upcasts are always 
trivial, even when the designated initializer isn’t.) We should be able to 
easily copy/type-pun between Array with Array, where T is 
either Int16 or another type-copy that (eventually) trivially shadows Int16. 
(Of course, this applies to Unsafe*Pointer or fixed-size arrays (if added) 
too.) These optimizations can’t be done with non-trivial type copies, since 
downcasts (and the downcast parts of cross-casts) need to have their designated 
initializers called for each element.

1. Now we get to the question in the Subject. Before now, I just wanted the 
compiler to see the definition of the designated initializer to determine if 
the type-copy is trivial or not. Now I realize that may have problems. One is 
that it may not be easy for the compiler to check if a given initializer 
matches the form I gave in the “MyResourceID” example. Another is that if the 
user prints out a prototype summary of the type, with members but without their 
definitions, s/he would have no idea if the type-copy was trivial or not.

I’m wondering if we should define trivial-ness with a keyword added to the 
definition:

typecopy MyResourceID1 trivial: Int16, Hashable {
// Initializer not given
publish Equatable
var hashValue: Int { get{return rawValue.hashValue & 0x01} }
}

typecopy MyResourceID2: Int16, Hashable {
trivial init(rawValue: RawValue)  // Looks incomplete, but it’s actually the 
full thing
publish Equatable
var hashValue: Int { get{return rawValue.hashValue & 0x01} }
}

typecopy MyResourceID3: Int16, Hashable {
init(rawValue: RawValue) = trivial
publish Equatable
var hashValue: Int { get{return rawValue.hashValue & 0x01} }
}

I kind-of like the look of the second, but it may be confusing to (new) users 
since there’s no code block after the initializer declaration. My next-liked 
look is the first one, but I’m not sure where the “trivial” should go (before 
“typecopy”, after it, current spot, or before the original type’s name after 
the colon). The third choice looks the weirdest to me, but it’s probably the 
easiest parsing-wise. It does remind me of the C++ class built-in 
life-management overrides.

(Now completing the post, maybe option 3 isn’t the easiest to parse. We go from 
“init” then Code-Block to “init” then either Code-Block or “= trivial”.)

For actual use, I’m leaning on placing “trivial” right before the original 
type’s name but after the colon. What does everyone else think?

1a. If “trivial” is added to the “typecopy” line, should explicitly defining a 
designated initializer anyway be banned? I’m leaning towards yes.

2. If no initializers are declared, either directly or with a publish, then a 
designated initializer is automatically added. It would have the same form as 
the one I gave in the example. If “trivial” goes inside the initializer’s 
declaration instead of the “typecopy” 

Re: [swift-evolution] “Integer” protocol?

[Daryle Walker via swift-evolution]

Sent from my iPad

> On Oct 31, 2017, at 10:55 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> Right, these issues were discussed when the proposal was introduced and 
> reviewed three times. In brief, what was once proposed as `Integer` was 
> renamed `BinaryInteger` to avoid confusion in name between `Integer` and 
> `Int`. It was also found to better reflect the semantics of the protocol, as 
> certain functions treated the value not merely as an integer but operated 
> specifically on its binary representation (for instance, the bitwise 
> operators).
> 
> Do not confuse integers from their representation. Integers have no intrinsic 
> radix and all integers have a binary representation. This is distinct from 
> floating-point protocols, because many real values representable exactly as a 
> decimal floating-point value cannot be represented exactly as a binary 
> floating-point value.

Abstractly, integers have representations in nearly all real radixes. But 
mandating base-2 properties for a numeric type that uses something else 
(ternary, negadecimal, non-radix, etc.) in its storage is definitely 
non-trivial. Hence the request for intermediate protocols that peel off the 
binary requirements. 

> To your specific question about bitwise operators: their semantics are with 
> respect to the two's-complement binary representation of the integer 
> regardless of the actual internal representation. `~` returns the one's 
> complement of the two's-complement binary representation of the integer. 
> FWIW, this is exactly what `mpn_com()` does in GNU MP for arbitrary-precision 
> integers.

To continue your own analogy, integers by themselves don’t have radix (or 
reduced-radix) complements. The complements depend on a fixed width, since 
they’re based on Radix ** Width modulo arithmetic (or Radix ** Width - 1 for 
the reduced-radix complement). 

15 has a two’s complement under a binary representation with N bits (where N is 
at least 4). It has a ones’ complement too. Doing any complement of 15 without 
an N is non-sensical; the result effectively would have an infinite number of 
ones at its beginning. I guess GNU-MP is stopping at the width of the original 
number’s storage, but that doesn’t make it right (although it’s more 
practical).  That’s why complements should be under the fixed-width protocols, 
not the general integer ones. 

The very existence of BinaryInteger is proof of allowing protocols for types 
that don’t exist in the Standard Library (yet). (In other words, if protocols 
had to be justified with a current algorithm or type to be in the SL, then 
BinaryInteger should be purged since there’s no current type that uses it 
without using FixedWidthInteger too.) I just think the hierarchy needs a little 
more tweaking. 


> 
> On Tue, Oct 31, 2017 at 7:23 PM, Max Moiseev via swift-evolution 
> <swift-evolution@swift.org> wrote:
>> Just for the reference. There was a lengthy discussion here in the mailing 
>> list back when the proposal was introduced:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/thread.html#30191
>> 
>> Max
>> 
>>> On Oct 31, 2017, at 5:15 PM, Daryle Walker via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Looking at Apple’s Swift (4) docs at their SDK site, shouldn’t there be an 
>>> “Integer” protocol between Numeric and BinaryInteger? Without that, there’s 
>>> no solution for Integer types that are either a non-binary radix or a 
>>> non-radix system (besides being over-broad with Numeric).
>>> 
>>> What would move there are: isSigned, quotientAndRemainder, signum, %, %=, 
>>> /, and /=.
>>> 
>>> Also, how is ~ supposed to work in a BinaryInteger that is not a 
>>> FixedWidthInteger? Extend the high bits to infinity? Maybe that operator 
>>> should move to the derived protocol.
>>> 
>>> Oh, why can’t a non-binary Integer type be fixed-width? FixedWidthInteger 
>>> should be renamed “FixedWidthBinaryInteger,” which derives from 
>>> BinaryInteger and a new version of FixedWidthInteger. The new version peels 
>>> off: max, min, addingReportingOverflow, dividedReportingOverflow, 
>>> dividingFullWidth, multipliedFullWidth, multipliedReportingOverflow, 
>>> remainderReportingOverflow, and subtractingReportingOverflow. There’s also 
>>> a “digitWidth” type property, analogous to “bitWidth”.
>>> 
>>> Sent from my iPad
>>> ___
>>> 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

[swift-evolution] “Integer” protocol?

[Daryle Walker via swift-evolution]

Looking at Apple’s Swift (4) docs at their SDK site, shouldn’t there be an 
“Integer” protocol between Numeric and BinaryInteger? Without that, there’s no 
solution for Integer types that are either a non-binary radix or a non-radix 
system (besides being over-broad with Numeric).

What would move there are: isSigned, quotientAndRemainder, signum, %, %=, /, 
and /=.

Also, how is ~ supposed to work in a BinaryInteger that is not a 
FixedWidthInteger? Extend the high bits to infinity? Maybe that operator should 
move to the derived protocol.

Oh, why can’t a non-binary Integer type be fixed-width? FixedWidthInteger 
should be renamed “FixedWidthBinaryInteger,” which derives from BinaryInteger 
and a new version of FixedWidthInteger. The new version peels off: max, min, 
addingReportingOverflow, dividedReportingOverflow, dividingFullWidth, 
multipliedFullWidth, multipliedReportingOverflow, remainderReportingOverflow, 
and subtractingReportingOverflow. There’s also a “digitWidth” type property, 
analogous to “bitWidth”.

Sent from my iPad
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Standard error?

[Daryle Walker via swift-evolution]

Been looking at the Swift standard library pages at Apple’s website. There’s 
“print” and “readLine” for I/O to/from standard output/input. Put there seems 
to be no function for standard error. The “print” function has an overload for 
custom streams, but there doesn’t seem to be an object that represents standard 
error that could go there. 

Is there a TextOutputStream object for standard error? Or does that have to be 
added? I wonder if it should be a global or a type-level property somewhere?

Sent from my iPad
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Find/split on sub-string/sequence

[Daryle Walker via swift-evolution]

There are sequence/collection/string methods to find an element/character or 
split a container on an element or one of a set of elements. But I haven't 
noticed methods that split on a sub-string, like wanting to split a string on 
exactly CR-LF and not on either individually. 

Shouldn't we add that? And a general version for sequences/collections. (I 
don't know if either the searched object and/or the match sub-object need to be 
a sequence or a collection.)

Sent from my iPhone
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Daryle Walker via swift-evolution]

> On Aug 19, 2017, at 3:29 PM, Haravikk via swift-evolution 
>  wrote:
> 
>> On 19 Aug 2017, at 19:46, Daryle Walker > > wrote:
>> 
>>> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution 
>>> > wrote:
>>> 
>>> Agreed. To be clear though; in spite of my pessimism this is a feature that 
>>> I do want, but I would rather not have it at all than have it implemented 
>>> in a way that hides bugs and sets a horrible precedent for the future.
>> 
>> I tried to make a split thread for this, but would you object to synthesized 
>> conformance if we had to explicitly add a command within the definition 
>> block to trigger the synthesis? If we add strong type-aliases, we could 
>> reuse the directive to copy an interface (method, inner type, property, or 
>> conformed-to protocol) from the underlying type to the current type for 
>> synthesis too. The only problem would be backward compatibility; once added, 
>> we would urge users to explicitly list “publish Equatable” for synthesis, 
>> but what about code that already uses the implicit version (since this 
>> feature will probably be released for at least one Swift version by the time 
>> strong type-aliases happen), do we force users to change their code?
> 
> I would rather no code at all use the implicit version; one of my points is 
> that it's not something that's easily changed after the fact, which is why it 
> needs to be done correctly now.
> 
> I'm open to any method that makes opting in to the synthesised conformance 
> explicit; I still think a specifically named protocol is the simplest, but 
> I'm not married to that as a solution; attributes, keywords etc. are all fine 
> too, whatever is the easiest way to opt-in to the behaviour explicitly 
> without ambiguity. I'm not 100% sure exactly what you mean by "add a command 
> within the definition block", or is an attribute/keyword what you meant?

The syntax to copy an interface from an underlying type to one of its strong 
type-aliases is a new directive within the definition block:

alter MyInt16: Int16, Hashable {
publish Equatable  // Automatically copies definitions from Int16 needed to 
conform to Equatable
var hashValue: Int { /*…*/ }  // A protocol can be completed with a mix of 
published and direct definitions
}

Since we would be introducing an explicit way to declare implementation of a 
conformance (the “publish” directive), we could reuse the directive for 
Equatable/Hashable/Encodable/Decodable definitions in non-strong-aliases and 
make the current implicit definitions obsolete. The problem then would be 
backwards compatibility; could we force users to go from implicit to explicit 
synthesized conformance?

The original point of publishing is to selectively control which parts of the 
underlying type’s interface get copied. Automatically synthesized conformance, 
if it stays after strong type-aliases are introduced, would screw with that 
(unless synthesized conformance is ignored for strong type-aliases; i.e. our 
conformance exception gets a counter exception).

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] Preparing Swift compiler stage reentrancy in preparation for "constexpr"

[Daryle Walker via swift-evolution]

[I’m not sure which list should cover this.]

I once thought of having a “#protocols(SomeTypeOrProtocol)” that was a type 
alias to a composition of all protocols the given type/protocol conforms to (or 
“Any” if none). It seems simple, but all current uses of protocols requires 
explicit mentions by the user, while this new facility would require looking 
back at the table of existing protocols.

It seems that implementing something like C++’s “constexpr” would have the same 
problem. The compiler stages can’t be one way anymore; a non-literal that’s 
needed for a compile-time context has to be deferred until its components can 
be evaluated in compile-time contexts (down to literals). So we would partially 
evaluate down to SIL, run the SIL in the compiler’s environment to determine 
all the compile-time data (not a big deal for discrete data, but we’ll have to 
ignore differences between the compiler’s environment and the target platform’s 
environment w.r.t. floating-point processing), then go back to the semantic 
phase to fill in the “constexpr” constants and evaluate the SIL again, possibly 
taking several cycles depending how deep “constexpr” is needed.

As an example, take a mythical function that converts a mythical 
one-dimensional fixed-size array to a tuple:

func tuple(from: [N; T]) -> ( #dup(N ; T) )

We would have to defer the return type until each call of “tuple(from:)”, where 
we look at the input’s type’s shape to determine N, then expand the #dup, then 
run the semantic phase again with the final type. What if N itself was based 
off a “constexpr” function? Then we would need (at least) two passes.

Should we start preparing the compiler stages for loopback now? Or do we have 
to figure out what exactly we want “Swift constexpr” to mean first?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Daryle Walker via swift-evolution]

> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution 
>  wrote:
> 
>> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de > wrote:
>>> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution 
>>> >:
>>> For me the whole point of a basic protocol is that it forces me to 
>>> implement some requirements in order to conform; I can throw a bunch of 
>>> protocols onto a type and know that it won't compile until I've finished 
>>> it, developers get distracted, leave things unfinished to go back to later, 
>>> make typos etc. etc. To me declaring a conformance is a declaration of "my 
>>> type will meet the requirements for this make, sure I do it", not "please, 
>>> please use some magic to do this for me"; there needs to be a clear 
>>> difference between the two.
>> 
>> My conclusion isn't as pessimistic as yours, but I share your objections: 
>> Mixing a normal feature (protocols) with compiler magic doesn't feel right 
>> to me — wether it's Equatable, Hashable, Codable or Error.
>> It's two different concepts with a shared name*, so I think even 
>> AutoEquatable wouldn't be the right solution, and something like #Equatable 
>> would be a much better indicator for what is happening.
>> 
>> Besides that specific concern, I can't fight the feeling that the evolution 
>> process doesn't work well for proposals like this:
>> It's a feature that many people just want to have as soon as possible, and 
>> concerns regarding the long-term effects are more or less washed away with 
>> eagerness.
>> 
>> - Tino
>> 
>> * for the same reason, I have big concerns whenever someone proposes to blur 
>> the line between tuples and arrays
> 
> Agreed. To be clear though; in spite of my pessimism this is a feature that I 
> do want, but I would rather not have it at all than have it implemented in a 
> way that hides bugs and sets a horrible precedent for the future.

I tried to make a split thread for this, but would you object to synthesized 
conformance if we had to explicitly add a command within the definition block 
to trigger the synthesis? If we add strong type-aliases, we could reuse the 
directive to copy an interface (method, inner type, property, or conformed-to 
protocol) from the underlying type to the current type for synthesis too. The 
only problem would be backward compatibility; once added, we would urge users 
to explicitly list “publish Equatable” for synthesis, but what about code that 
already uses the implicit version (since this feature will probably be released 
for at least one Swift version by the time strong type-aliases happen), do we 
force users to change their code?

> I realise I may seem to be overreacting, but I really do feel that strongly 
> about what I fully believe is a mistake. I understand people's enthusiasm for 
> the feature, I do; I hate boilerplate as much as the next developer, but as 
> you say, it's not a reason to rush forward, especially when this is not 
> something that can be easily changed later.
> 
> That's a big part of the problem; the decisions here are not just about 
> trimming boilerplate for Equatable/Hashable, it's also about the potential 
> overreach of every synthesised feature now and in the future as well.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

[Daryle Walker via swift-evolution]

> On Aug 17, 2017, at 1:06 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Also, for those of you here who haven't heard my previous rant on the 
> subject, I dislike using map for generating values that don't depend on 
> transforming a domain to a range. (It has been argued that `_ in` is mapping 
> from `Void`, but I still dislike it immensely)
> 
> Here are the ways that I have approached this:
> 
> // Ugh
> [UIView(), UIView(), UIView(), UIView(), UIView()]

What if we got a duplication “macro”:

[ #dup(5 ; UIView()) ]

It’s not a true macro because it reads the count when “constexpr” objects would 
be evaluated.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] What would public/open mean for a subtype? (was: Enums and Source Compatibility)

[Daryle Walker via swift-evolution]

> On Aug 9, 2017, at 3:57 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’d very much in favour of a consistent access modifiers across the whole 
> language and eliminate exclusive `open`. `open/public` protocols are more 
> than welcome. Plus it’s already has been said that Swift will potentially 
> support subtyping for value type in some future, where we’ll yet again would 
> need to align what `public` and `open` will mean. So I’d appreciate all the 
> steps that could already be made now to align their meaning as much as it’s 
> possible to this moment.

I have a proposal for “alternative types,” which can fulfill the “strong 
typedef” desired feature from C++. Since I changed from a custom initialization 
interface to RawRepresentable, I can do conditional translation to the new 
type, i.e. implement subtypes. (It can also do quotient types.) What do you 
mean by needing to figure out what public/open mean?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] How does "Sequence.joined" work?

[Daryle Walker via swift-evolution]

> On Aug 9, 2017, at 12:19 PM, Taylor Swift <kelvin1...@gmail.com> wrote:
> 
> On Wed, Aug 9, 2017 at 10:43 AM, Daryle Walker via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> On Aug 8, 2017, at 6:45 PM, Geordie Jay <geo...@gmail.com 
>> <mailto:geo...@gmail.com>> wrote:
>> 
>> Daryle Walker via swift-evolution <swift-evolution@swift.org 
>> <mailto:swift-evolution@swift.org>> schrieb am Di. 8. Aug. 2017 um 21:25:
>>> On Aug 8, 2017, at 12:35 AM, Félix Cloutier <felixclout...@icloud.com 
>>> <mailto:felixclout...@icloud.com>> wrote:
>>> 
>>> All this means is that `joined()` does not create an array that contains 
>>> the new result. It's only as magic as the COW semantics on arrays.
>> 
>> So you’re saying the COW semantics for Array and other standard library 
>> types have secret references/pointers that work even for “let”-mode objects, 
>> and the Sequence variants the various forms of “joined” need use a 
>> Sequence/Collection of those secret references?
>> 
>> I know nothing about this specific type under the hood and your question 
>> stumped me when I first saw it as well, so take this with a grain of salt:
>> 
>> I think it's basically just storing the arrays internally (as let) and when 
>> you iterate through the collection it just goes through the subsequences one 
>> by one, when the last index of the first is reached it begins with the next 
>> subsequence.
>> 
>> As for how it avoids creating new storage, simple. As someone else 
>> mentioned, this is no more magic than Copy On Write for normal arrays.
>> 
>> let a = [1,2,3]
>> let b = a // this doesn't produce a copy of the underlying buffer.. I.e. 
>> value semantics but only one buffer needed
>> 
>> ^^^ This is the take-home message. And your intuition about COW is correct: 
>> its internal storage is a reference type containing a buffer pointer. When 
>> (and only when) a mutation occurs, the buffer is copied and the new storage 
>> becomes the backing for the resulting struct. Any existing copies remain 
>> unchanged (and truly immutable) because they keep their original storage.
>> 
>> https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift
>>  
>> <https://github.com/apple/swift/blob/master/stdlib/public/core/ContiguousArrayBuffer.swift>
>> 
>> 
>> So with that understanding of COW, it becomes easy to imagine all sorts of 
>> containers that don't require additional storage for their contents:
>> 
>> struct JoinedSequenceOfThreeArrays {
>>   let array1: [T]
>>   let array2: [T]
>>   let array3: [T]
>> }
>> 
>> // still only one array buffer storage is required for all of this:
>> let c = JoinedSequenceOfThreeArrays(array1: a, array2: a, array3: b)
>> 
>> Does that make sense?
> 
> Mostly, then I realized a flaw with this explanation. Your theory implies 
> that “joined” avoids creating new storage by betraying that and actually 
> copying the containers, but said containers use-COW/reference-remote-storage 
> themselves. Then what happens when a Sequence uses scoped storage for its 
> items? (Example: the mythical “just slap Collection on a tuple and call it an 
> array” type.) Either “joined” uses a different no-copy technique or it’s 
> lying about saving on storage (and the lack of scoped-storage Sequences means 
> no one has called them on it yet).
> 
> I don’t see any contradiction here. A tuple is a value type; it has no 
> concept of copy-on-write because it’s copy-on-read. So JoinedSequence will 
> store a copy of the tuple instead of a buffer reference

Besides meaning the explanation for “joined” is lying, what if the value type 
is large enough that copies should be minimized?

Hmm, it seems that there’s a hole in the language in that value-type “let”-mode 
instances cannot be aliased/referenced.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] How does "Sequence.joined" work?

[Daryle Walker via swift-evolution]

> On Aug 8, 2017, at 12:35 AM, Félix Cloutier <felixclout...@icloud.com> wrote:
> 
> All this means is that `joined()` does not create an array that contains the 
> new result. It's only as magic as the COW semantics on arrays.

So you’re saying the COW semantics for Array and other standard library types 
have secret references/pointers that work even for “let”-mode objects, and the 
Sequence variants the various forms of “joined” need use a Sequence/Collection 
of those secret references?

>> Le 7 août 2017 à 21:12, Daryle Walker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>> 
>> I was looking at random items at SwiftDoc.org <http://swiftdoc.org/>, and 
>> noticed the “FlattenBidirectionalCollection” structure. It helps implement 
>> some versions of “joined” from Sequence (probably when the Sequence is also 
>> a BidirectionalCollection). The directions for the type state that “joined” 
>> does not create new storage. Then wouldn’t it have to refer to the source 
>> objects by reference? How; especially how does it work without requiring a 
>> “&” with “inout” or how it works with “let”-mode objects? Or am I 
>> misunderstanding how it works behind the covers?
>> 
>> (If there is a secret sauce to have one object refer to another without 
>> “&”/“inout”/“UnsafeWhateverPointer”, I like to know. It may help with 
>> implementing an idea. The idea involves extending the language, so “compiler 
>> magic” that the user can’t access is OK; I’d just claim to use the same 
>> sauce in my proposal.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch][Swift 5?] #dup "macro", i.e. Entity Duplication

[Daryle Walker via swift-evolution]

I posted a revision (2) of the entity duplication 
. I added 
the ability to use the index placeholder as a closure anonymous argument, i.e. 
parameterize “$0,” “$1,” etc. with “$($$0).” I thought a direct 
triple-dollar-sign would be confusing, from determining which order the “$” and 
“$$” bind (or if it’s yet another new token).

I don’t think anyone has looked at this yet. I do want it for Swift 5, if 
possible. It’s the dual to variadic parameters/arguments; for producing 
comma-separated lists (instead of consuming), but can be used for non-variadic 
stuff too.  “constexpr” would help, but it’s not necessary. It would complement 
variadic generics, if added.

I want to know if the grammar scheme (the one in the “Grammar” section, not the 
troll version a few paragraphs before) is the good approach. And if the idea is 
even feasible to implement.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] How does "Sequence.joined" work?

[Daryle Walker via swift-evolution]

I was looking at random items at SwiftDoc.org , and 
noticed the “FlattenBidirectionalCollection” structure. It helps implement some 
versions of “joined” from Sequence (probably when the Sequence is also a 
BidirectionalCollection). The directions for the type state that “joined” does 
not create new storage. Then wouldn’t it have to refer to the source objects by 
reference? How; especially how does it work without requiring a “&” with 
“inout” or how it works with “let”-mode objects? Or am I misunderstanding how 
it works behind the covers?

(If there is a secret sauce to have one object refer to another without 
“&”/“inout”/“UnsafeWhateverPointer”, I like to know. It may help with 
implementing an idea. The idea involves extending the language, so “compiler 
magic” that the user can’t access is OK; I’d just claim to use the same sauce 
in my proposal.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

[Daryle Walker via swift-evolution]

> On Aug 3, 2017, at 12:39 AM, Daryle Walker  wrote:
> 
> After a few hours, I figured out what was bugging me. Variadic generic 
> parameters, and the existing variadic function parameters, CONSUME 
> arbitrarily long comma-separated lists. The #dup facility PRODUCES those 
> kinds of lists. The features are duals, not the same. The features can 
> synergize.

I just upload a rough proposal at 
.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Daryle Walker via swift-evolution]

> On Aug 3, 2017, at 8:20 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
>>> The root cause, of course, is that the VLAs require new stack allocations 
>>> each time, and the stack is only deallocated as one lump when the frame 
>>> ends.
>> 
>> That is true of alloca(), but not of VLAs.  VLAs are freed when they go out 
>> of scope.
> 
> Learned something today.
> 
> Anyway, if the goal is stack allocation, I would prefer that we explored 
> other ways to achieve it before jumping to a new array-type. I’m not really a 
> fan of a future where [3; Double] is one type and (Double, Double, Double) is 
> something else, and Array is yet another thing.

Just about every system programming language has all three of these, since you 
can’t really stop these “similar” types from co-existing. The third type uses 
remote storage, while the first two are scoped storage. A heterogenous product 
type template has to include homogenous product types as a subset. And 
instruction generators can produce different code between tuples and arrays; 
are you willing to forfeit one set of optimizations?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Aug 3, 2017, at 7:20 AM, Tino Heth <2...@gmx.de> wrote:
> 
> Hi Daryle,
> 
> I think we agree a lot on the importance of fixed-size arrays, but have a 
> different opinion on which aspect is the most valuable… (so we now only have 
> to agree that mine is better ;-) ;-)
> My motivation for FSA is safety and convenience:
> I want to iterate over C arrays in a straightforward way, but primarily, I 
> don't want to accidentally multiply a vector of size 3 with a 2×2 matrix.

Data modeling is important for me too. That’s why the proposal includes 
multi-dimensionality and why I didn’t just jam in Collection support. We don’t 
want to add conformance then find out that was a mistake.

> Of course, fast is cool, but I don't expect to suffer from bad performance 
> because of implementation details like how, where and when memory allocation 
> happens.
> Your focus, on the other hand, seems to be performance:
> You don't want to give guarantees about the order because of (hypothetical?) 
> optimisations that could be blocked by that, and avoid initialisation 
> overhead.

I also don’t want to block parallel/vector processing.

let a: @vector [4; Int] = //…
let b: @vector [4; Int] = //…
var c: @vector [4; Int] = //…
//…
loop: for i in a {
c[ #indexOf(loop) ] = i * b[ #indexOf(loop) ]
}
//…

I want the compiler to potentially be able to see that the elements are being 
computed in formation and use vector-unit instructions instead of serial 
processing.

> You brought "withUnsafeFlattening" to the table to add convenience, but I 
> think that is the wrong direction:
> Safe should be default, and it's quite common that you have to live with 
> "unsafe" when you need "fast".

The name has “Unsafe” because the Collection type used, UnsafeBufferPointer, 
does. I don’t know enough about what makes the existing “Unsafe” API that way 
for the flattening function to declared “safe”. It could be safe for all I know.

A substitute Collection-access function besides “withUnsafeFlattening” would 
either copy the elements (i.e. be inefficient, especially for large arrays) or 
somehow secretly maintain a reference to the array in memory. The latter would 
then be “withUnsafeFlattening” with a prettier name.

My first reason for “withUnsafeFlattening” was to allow API to use any FSA of a 
given element type, no matter the shape.

> As you don't want to confirm to Sequence at all, it shouldn't bother you if 
> the iterator sacrifices a tiny bit of performance in exchange for a reliable 
> order, and when you really need piecemeal initialisation, you could take a 
> FSA-Variant that skips initialisation of elements.
> Of course, that wouldn't be ideal, and there should be an "Unsafe" in the 
> name of that type — but I don't think tuple-like delayed initialisation would 
> help when solving real-world problems:
> The "x.0 = 0; x.1 = 1" case is trivial and can be done with normal init, and 
> when this isn't enough, you most likely loose all guarantees because you use 
> a loop to fill that array*.

Using a loop for array initialization is why I suggested we should look into 
run-time DI, which should be kept to restricted circumstances.

> I really appreciate the effort you spend for digging into the low-level 
> details, and hope that we end up with a draft that satisfies your use case.
> 
> - Tino
> 
> * There are actually cases where you want to compute the value of one element 
> based on another one, but that might as well be an indicator that you are 
> better off with a tuple, instead of using an array.
> 
>>> So would you say Dictionary shouldn't conform to Collection either?
>>> Just because a type conforms to a protocol doesn't mean it can't add its 
>>> own methods on top.
>> 
>> But the FSA interface and the Sequence/Collection interface would be very 
>> similar, basically competing, leading to a schizophrenic interface. Since 
>> another part of the overall FSA interface implements Collection, just use 
>> that.
> Yes, I can't argue against the claim that Collection sometimes feels a little 
> bit odd :-( — but it is what it is, and maybe there will be improvements in 
> the future that could take into account the experience with FSA.
> 
>>> Swift has one-dimensional arrays, and they support Collection... this may 
>>> sound like nitpicking that only works because there is no explicit 
>>> "fixed-size" in you statement, but feel free to prove me wrong for FSAs.
>> 
>> Yes, I meant FSAs, not both them and Array; it’s long-winded to keep adding 
>> the “fixed-size” part.
> So we do agree that there is no fundamental reason that stops FSAs from being 
> collections? ;-)

Besides that they can’t be Sequences, unless you throw away allowing 
parallel/vector processing in the future. (That can’t be bolted onto Version 2, 
since committing to Sequence means you committed to single-thread iteration.) 
Just found out that C++ 17 (optionally) adds parallel/vector processing to its 
for-loops. I guess I caught on to a 

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
> I’m -1 on adding a fixed-sized Array type.
> 
> It goes back to something which I remember reading from John McCall earlier 
> this week but can’t find any more: about tuple indices being nominal and not 
> ordinal. How do fixed-size Arrays differ? Are their indexes truly not nominal?

I think he meant that the numbered names for tuple members were originally (?) 
there because the Swift authors didn’t mandate each member needing a label, so 
there needed some way to refer to unnamed members. Note that numbered names are 
not true integer variables, not even useable as such. Array indexes are 
programmable objects; algorithms on the indexes is how we select array subsets 
to apply algorithms on.

> The difference between a fixed-size array and the dynamically-sized Array we 
> already have is that the programmer expects specific data at each element. 
> Maybe it’s elements of a vector or matrix, or some other structure, but in 
> general I think that constraints about the size/shape of the sequence implies 
> expectations about what you’re going to find at each location. Maybe you 
> would normally write a struct for it, but it’s not worth writing out. In that 
> sense, how is it different from a homogenous tuple?

I’m not sure what you mean here. How do elements of dynamically-sized arrays 
not have expectations?

The big innovation arrays (and loops) brought was no longer having a 
per-sub-object declaration/command for elements. Just tweak a number.

I’m not good at explicit explanations, so having to justify adding a type 
that’s been around for a long time (at least FORTRAN 4+ decades ago) an almost 
every systems programming language has is frustrating. I thought the desire 
would be obvious; if there were FSAs in Swift 1, would there be any “just slap 
Collection on tuples and be done with it” suggestions now? It doesn’t help that 
I still don’t know why FSAs where skipped in Swift 1; did they forget or was 
there some high-level type-theory reason? (Were the type description records in 
the Swift ABI too fragile for a type that wouldn’t have per-sub-object entries 
(assuming theoretical Swift-1-FSAs weren’t translated to massive homogenous 
tuples)?)

I mentioned in my proposal that no language (that I know of) splatted tuple and 
array syntax together, either declaration syntax or dereferencing syntax. (Lua 
has shared dereferencing syntax, but they both rip-off dictionaries.) Where do 
people think every one else over the last few decades went wrong?

Maybe there’s a copy of the FORTRAN design documents out there?...

> Also, what effect would this have on Array as the common-currency for simple 
> lists? And what about the literals - does [myObj, anotherObj] give you a 
> [MyObject] or a [2; MyObject]? Is that what users will intuitively expect? 
> What about if it’s a “let” constant?

Later revisions of the proposal have a distinct grid literal syntax, to clear 
up any potential confusion. The standard array literals would map to Array. The 
grid literal, which includes the dimensions of the array before a list of each 
value, would map to a fixed-size array.

> So overall, I’m unconvinced of the need for fixed-size arrays. My 
> counter-proposal would be a shorthand syntax for more conveniently defining 
> homogenous tuples, and keep them as our go-to objects for ad-hoc groups of 
> things. That’s it. If you would have used a fixed-size Array in C, keep using 
> homogenous tuples in Swift.
> 
> As for the part about the @vector and @parallel attributes, those would be 
> worth a separate proposal. As for @parallel, I suggested something like that 
> before but Dave Abrahams said any such support would look more like a generic 
> concurrent wrapper, e.g. 
> https://gist.github.com/karwa/43ae838809cc68d317003f2885c71572 
> . Vector 
> support is worth thinking about in a separate proposal.

A main point for my FSA design is that I want to allow the default iteration 
primitive (for-loop) to have a vectorized/parallel implementation (someday). 
Since Sequence/Collection always has a sequential traversal policy (It’s in the 
name!), it’s the main reason FSA don’t directly conform to Collection in the 
design.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

[Daryle Walker via swift-evolution]

> On Aug 1, 2017, at 9:56 AM, Daryle Walker <dary...@mac.com> wrote:
> 
>> On Jul 31, 2017, at 10:38 PM, David Sweeris <daveswee...@mac.com 
>> <mailto:daveswee...@mac.com>> wrote:
>> 
>>> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> The tuple will be a bunch of “T,” but the count mechanically added depends 
>>> on compiler-visible number N. Well, since this is part of a proposal that 
>>> already mutates the language, I thought why not add a primitive operation 
>>> by fiat:
>>> 
>>> func tuple<T, N: Int>(from: [N; T]) -> ( #dup(N; T) )
>>> 
>>> where “#dup” dumps a comma-separated list repeating the right-side entity 
>>> with a multiplicity of the left-side value. The left-side value has to be a 
>>> compiler constant expression. I was going to have the right side be an 
>>> arbitrary token sequence, but I think it’s better for now to limit it to 
>>> either a type (or similar) or an expression. Obviously, the receiver has to 
>>> compatible with whatever being dumped there.
>> 
>> We've been talking about adding Variadic Generic Parameters for a while, and 
>> I'm pretty sure that the functionality you're suggesting here would be a 
>> subset of that. We're just waiting for it to come into scope.
> 
> I don’t think this functionality is covered by variadic generic parameters.

After a few hours, I figured out what was bugging me. Variadic generic 
parameters, and the existing variadic function parameters, CONSUME arbitrarily 
long comma-separated lists. The #dup facility PRODUCES those kinds of lists. 
The features are duals, not the same. The features can synergize.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Aug 1, 2017, at 7:21 PM, John McCall <rjmcc...@apple.com> wrote:
> 
>> On Aug 1, 2017, at 5:49 PM, David Sweeris via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>>> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> A tuple can have its members initialized in piecemeal and still satisfy 
>>> deterministic initialization. The named types need to do all their 
>>> sub-objects' initializations before any designated initializer ends. I want 
>>> the former for array instances, not the latter. It’s important for numeric 
>>> applications, so math arrays don’t have to be set twice, once for an 
>>> arbitrary default and again for the real data.
>> 
>> Eh? What do you mean by "initialized in piecemeal"? These both give errors:
>> let x:(Int, Int) = (0) // something about not being able to convert `Int` to 
>> `(Int, Int)`
>> let x:(Int, Int) = (0, _) // something about "_" only being allowed in 
>> patterns
>> 
>> Is that what you're talking about?
> 
> I think he means that you can do
> 
> var x: (Int,Int)
> x.0 = 0
> x.1 = 1
> 
> This is generally not allowed for other aggregates outside of initializers.

Yes, this.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Aug 1, 2017, at 1:03 PM, Tino Heth <2...@gmx.de> wrote:
> 
>> Sequence/Collection have other problems fitting with fixed-size arrays. 
>> There needs to be a new set of more basic protocols that both arrays and 
>> Sequence or Collection can conform to.
> What exactly is the problem with Sequence that makes you believe there is 
> need for a more basic protocol?

For one, the return value of map is wrong. Sequence.map returns an Array, since 
a Sequence may not be a container itself. Using Array may be a minor 
inconvenience for Collection. But it’s a huge surprise if a fixed-size array’s 
map doesn’t return another fixed-size array of the same shape (not necessarily 
the same element type).

>> Or to flip it, just use multi-dimensional arrays with one bound. 
>> Multi-dimensionality does not impose an implementation penalty
> I'd call the (imho extremely) increased complexity and loosing conformance to 
> Collection a heave penalty… actually, it would strip arrays of their biggest 
> unique feature compared to tuples.
> And after all, all arrays have to be mapped to a single dimension, so I don't 
> see the ability to define an array with ten dimensions on the fly as a big 
> win (because it's rather easy to derive such a type from a one-dimensional 
> array).

I said that not even one-dimensional arrays can support Collection by default, 
so ripping out multi-dimensional support won’t bring Collection back for 1D 
arrays. (Before that I was going to support Collection for just 1D arrays, so 
keeping multi-dimensional support or not wouldn’t change.)

Anyway, withUnsafe(Mutable)Flattening would be available as a standard global 
function for your Collection needs. It just isn’t built into the array types.

>> Wrapping multi-dimensionality in a type would forfeit it being a compound 
>> type, which would forfeit piecemeal initialization.
> [Basic question: What definition of compound type are you referring to?]

Compound types: functions and tuples. Versus named types: structures, classes, 
and enumerations.

> Why would there be a fundamental difference in initialisation between an 
> array, and an object that holds an array and maps to its contents?

A tuple can have its members initialized in piecemeal and still satisfy 
deterministic initialization. The named types need to do all their sub-objects' 
initializations before any designated initializer ends. I want the former for 
array instances, not the latter. It’s important for numeric applications, so 
math arrays don’t have to be set twice, once for an arbitrary default and again 
for the real data.

> [ah, I think I got that point: It's not about leaving parts uninitialised and 
> taking care of them later, but the ability to use literals like
> [[[0, 0, 1], [0, 1, 0]], [0, 0, 2], [0, 2, 0]]]
> right?]

It is about delaying initializations. But I don’t know what you mean about your 
statement about literals.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Aug 1, 2017, at 3:21 AM, Tino Heth <2...@gmx.de> wrote:
> 
>> FSAs intentionally don’t conform to Collection, because multi-dimensional 
>> arrays shouldn’t have to conform to a linear (by nature, hence the name 
>> “Sequence”) standard, at least by default.
> I strongly oppose and think it is a really bad idea:
> Even if arrays are modelled multi-dimensional, there's always a canonical way 
> to iterate through their elements, and this is an essential feature of this 
> data type.

But linear access isn’t an inherent canonical property of multi-dimensional 
arrays, it’s just a consequence of arrays taking a contiguous block of memory 
(which is generally treated as linear in computers).

Speaking of which, the “withUnsafe(Mutable)Flattening” functions give 
Collection access. (And it serves as an equivalent to the “T[]” function 
parameter interface from C.)

I was going to support Collection for one-dimensional arrays, but I realized 
that would be a bad idea since that’s the dimensionality that would exploit 
vector-unit types the most. So you must convert first. (Well, the “conversion” 
to an Unsafe(Mutable)BufferPointer should just type-pun the address, unless the 
array was not initially in conventional addressable memory, which (small) 
objects aren’t by default in Swift, hence the “Unsafe” part of Swift’s pointer 
interface.)

> Do you have any example for an existing optimisation that is important enough 
> to cripple all fixed size arrays?
> Those would not only be used to represent pixel buffers on a graphics card…

Sequence/Collection have other problems fitting with fixed-size arrays. There 
needs to be a new set of more basic protocols that both arrays and Sequence or 
Collection can conform to.

> Also, if FSA have only one dimension (that's still my preference), all those 
> issues are can be solved easily in the multidimensional structure build on 
> top of the array.

Or to flip it, just use multi-dimensional arrays with one bound. 
Multi-dimensionality does not impose an implementation penalty, especially when 
declaring a one-dimensional array. Wrapping multi-dimensionality in a type 
would forfeit it being a compound type, which would forfeit piecemeal 
initialization. There’s no need for Swift arrays to be limited to C arrays plus 
Assignability (or be just C arrays plus Assignability plus Collection).

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

[Daryle Walker via swift-evolution]

> On Jul 31, 2017, at 10:23 PM, Daryle Walker via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Could we do better than simple repetition? What if we define a “$$n” unit, 
> where “n” is a nonnegative integer. For each comma-separated item, the unit 
> will be replaced by increasing compiler-constant integers from zero. If using 
> an expression, maybe you can call a function on the double-dollar value to 
> get your own custom values there. This can be expanded to types once 
> value-based generic parameters get added.
> 
> When there are nested #dup calls, the double-dollar unit refers to the 
> counter for the innermost #dup. Maybe there can be a triple-dollar unit for 
> the immediately enclosing #dup. Even quadruple- or more-dollar units for the 
> outer levels. (Hopefully, nothing more that one level would be needed.)

Upon waking up, I realized I got this part of the idea completely wrong. Within 
the right side of a #dup, there is only one counter, so numbers wouldn’t be 
necessary after the “$$”.

However, we could use numbers to replace the triple-, quadruple-, etc. 
dollar-sign idea. So “$$0” is the counter for the current #dup, “$$1” is the 
counter for the immediately surrounding #dup, and higher numbers go for outer 
layers. Upon expansion, “$$0” goes to the index number of the comma-separated 
entity, while “$$n” goes to “$$(n - 1)”. It’s an error to still have 
double-dollar symbols remaining after the outermost #dup is expanded.

Oh, the right side of the #dup can take a type, an expression, or a 
comma-separated list of one of those.

Here’s an example using theoretical fixed-size arrays:

let tupleOf12 = ( (2, 3, 5, 7), (4, 6, 8, 9), (10, 11, 12, 1) )
let arrayOf12 = { 3, 4 ; #dup(3; #dup(4; tupleOf12 . $$1 . $$0 ) ) }
assert( tupleOf12.0.0 == arrayOf12[0, 0] )  // 2
//…
assert( tupleOf12.2.3 == arrayOf12[2, 3] )  // 1

So resolving the inner #dup gives:

#dup(3; tupleOf12 . $$0 . 0, tupleOf12 . $$0 . 1, tupleOf12 . $$0 . 2, 
tupleOf12 . $$0 . 3 )

And doing the remaining #dup gives:

tupleOf12 . 0 . 0, tupleOf12 . 0 . 1, tupleOf12 . 0 . 2, tupleOf12 . 0 . 3, 
tupleOf12 . 1 . 0, tupleOf12 . 1 . 1, tupleOf12 . 1 . 2, tupleOf12 . 1 . 3, 
tupleOf12 . 2. 0, tupleOf12 . 2 . 1, tupleOf12 . 2 . 2, tupleOf12 . 2 . 3

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

[Daryle Walker via swift-evolution]

> On Jul 31, 2017, at 10:38 PM, David Sweeris <daveswee...@mac.com> wrote:
> 
>> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> The tuple will be a bunch of “T,” but the count mechanically added depends 
>> on compiler-visible number N. Well, since this is part of a proposal that 
>> already mutates the language, I thought why not add a primitive operation by 
>> fiat:
>> 
>> func tuple<T, N: Int>(from: [N; T]) -> ( #dup(N; T) )
>> 
>> where “#dup” dumps a comma-separated list repeating the right-side entity 
>> with a multiplicity of the left-side value. The left-side value has to be a 
>> compiler constant expression. I was going to have the right side be an 
>> arbitrary token sequence, but I think it’s better for now to limit it to 
>> either a type (or similar) or an expression. Obviously, the receiver has to 
>> compatible with whatever being dumped there.
> 
> We've been talking about adding Variadic Generic Parameters for a while, and 
> I'm pretty sure that the functionality you're suggesting here would be a 
> subset of that. We're just waiting for it to come into scope.

I don’t think this functionality is covered by variadic generic parameters.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Daryle Walker via swift-evolution]

> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan  
> wrote:
> 
>> 
>> On Jul 31, 2017, at 11:23 PM, John McCall > > wrote:
>> 
>>> 
>>> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan >> > wrote:
>>> 
>>> 
 On Jul 31, 2017, at 10:09 PM, John McCall > wrote:
 
> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan 
> > 
> wrote:
>> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution 
>> > wrote:
>> 
>>> On Jul 30, 2017, at 11:43 PM, Daryle Walker >> > wrote:
>>> The parameters for a fixed-size array type determine the type's 
>>> size/stride, so how could the bounds not be needed during compile-time? 
>>> The compiler can't layout objects otherwise. 
>> 
>> Swift is not C; it is perfectly capable of laying out objects at run 
>> time.  It already has to do that for generic types and types with 
>> resilient members.  That does, of course, have performance consequences, 
>> and those performance consequences might be unacceptable to you; but the 
>> fact that we can handle it means that we don't ultimately require a 
>> semantic concept of a constant expression, except inasmuch as we want to 
>> allow users to explicitly request guarantees about static layout.
> 
> Doesn't this defeat the purpose of generic value parameters? We might as 
> well use a regular parameter if there's no compile-time evaluation 
> involved. In that case, fixed-sized arrays will be useless, because 
> they'll be normal arrays with resizing disabled.
 
 You're making huge leaps here.  The primary purpose of a fixed-size array 
 feature is to allow the array to be allocated "inline" in its context 
 instead of "out-of-line" using heap-allocated copy-on-write buffers.  
 There is no reason that that representation would not be supportable just 
 because the array's bound is not statically known; the only thing that 
 matters is whether the bound is consistent for all instances of the 
 container.
 
 That is, it would not be okay to have a type like:
  struct Widget {
let length: Int
var array: [length x Int]
  }
 because the value of the bound cannot be computed independently of a 
 specific value.
 
 But it is absolutely okay to have a type like:
  struct Widget {
var array: [(isRunningOnIOS15() ? 20 : 10) x Int]
  }
 It just means that the bound would get computed at runtime and, 
 presumably, cached.  The fact that this type's size isn't known statically 
 does mean that the compiler has to be more pessimistic, but its values 
 would still get allocated inline into their containers and even on the 
 stack, using pretty much the same techniques as C99 VLAs.
>>> 
>>> I see your point. Dynamically-sized in-place allocation is something that 
>>> completely escaped me when I was thinking of fixed-size arrays. I can say 
>>> with confidence that a large portion of private-class-copy-on-write value 
>>> types would greatly benefit from this and would finally be able to become 
>>> true value types.
>> 
>> To be clear, it's not obvious that using an inline array is always a good 
>> move for performance!  But it would be a tool available for use when people 
>> felt it was important.
> 
> That's why I'm trying to push for compile-time execution system. All these 
> problems (among many others) could be designed out of existence and the 
> compiler would be incredibly simple in the light of all the different 
> specific features that the community is asking for. But I do feel your urge 
> to avoid inventing a bulldozer factory just for digging a hole in a sandbox. 
> It doesn't have to be relied upon by the type checker or generic resolution 
> mechanism. It would be purely auxiliary. But that would single-handedly move 
> a large chunk of the compiler into stdlib and a huge portion of various 
> little incidental proposals would fade away because they can now easily be 
> implemented in Swift for specific purposes.
> 
> As far as I know, the pinnacle of uses for fixed-size arrays is having a 
> compile-time pre-allocated space of the necessary size (either literally 
> at compile-time if that's a static variable, or added to the pre-computed 
> offset of the stack pointer in case of a local variable).
 
 The difference between having to use dynamic offsets + alloca() and static 
 offsets + a normal stack slot is noticeable but not nearly as extreme as 
 you're imagining.  And again, in most common cases we would absolutely be 

[swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

[Daryle Walker via swift-evolution]

When coming up with new array interfaces, I had some array to/from tuple 
conversion functions:

func array(from: (T, …U)) -> [1 + #countOf(U) ; T] allwhere U == T

The problem is going the other way:

func tuple(from: [N; T]) -> ???

The tuple will be a bunch of “T,” but the count mechanically added depends on 
compiler-visible number N. Well, since this is part of a proposal that already 
mutates the language, I thought why not add a primitive operation by fiat:

func tuple(from: [N; T]) -> ( #dup(N; T) )

where “#dup” dumps a comma-separated list repeating the right-side entity with 
a multiplicity of the left-side value. The left-side value has to be a compiler 
constant expression. I was going to have the right side be an arbitrary token 
sequence, but I think it’s better for now to limit it to either a type (or 
similar) or an expression. Obviously, the receiver has to compatible with 
whatever being dumped there.

…

Could we do better than simple repetition? What if we define a “$$n” unit, 
where “n” is a nonnegative integer. For each comma-separated item, the unit 
will be replaced by increasing compiler-constant integers from zero. If using 
an expression, maybe you can call a function on the double-dollar value to get 
your own custom values there. This can be expanded to types once value-based 
generic parameters get added.

When there are nested #dup calls, the double-dollar unit refers to the counter 
for the innermost #dup. Maybe there can be a triple-dollar unit for the 
immediately enclosing #dup. Even quadruple- or more-dollar units for the outer 
levels. (Hopefully, nothing more that one level would be needed.)

…

Later, I remembered the "( 6 * TupleMemberType )” syntax for repeating a type 
within a tuple that's sometimes suggested. The #dup facility can be seen as a 
generalized version of that quasi-array-specific idea.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

[Daryle Walker via swift-evolution]

> On Jul 31, 2017, at 8:38 PM, Robert Widmann  wrote:
> 
>> On Jul 31, 2017, at 4:08 PM, Daryle Walker > > wrote:
>> 
>>> On Jul 31, 2017, at 1:45 PM, Robert Widmann >> > wrote:
>>> 
>>> Additionally, the use of inheritance in alternate definitions seems out of 
>>> place and the casting section breaks encapsulation.
>> 
>> Enumerations use similar syntax to specify their raw type. What word, which 
>> may have to be new, should be used to serve a similar function as “super” 
>> within the main initializer?
> 
> Treating an alternate like a protocol is fine - there is prior art in 
> protocols for that.  But having alternatives refine each other doesn’t make 
> much sense to me without a more salient example than the one in the proposal. 
>  

It’s more for being orthogonal; there’s no reason to ban it. Whatever value 
type you have: give me equal or fewer states and a clean break in the interface 
(which can be selectively added back). It doesn’t matter which kind of value 
type the source was. I guess almost no-one would cast more than to/from the 
immediate underlying type, but the very design of alternatives lets me do 
multiple levels for free. Type punning is generally the only thing needed, no 
code except for downcasts (or the downcast phase of cross-casts) of non-basic 
alternatives, which must be kept for safety.

>> Isn’t breaking (or at least bending) encapsulation a point of casting? And 
>> shorter than calling “rawValue” and/or “init?” a bunch of times?
> 
> A cast in C and C++ may be so, but we encourage checked casts where possible 
> and allow you access to the old “a promise to the compiler” kind of casting 
> with unsafeBitCast - and even then we check sizes.  We should try to avoid 
> leaking implementation details like this.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

[Daryle Walker via swift-evolution]

> On Jul 31, 2017, at 1:45 PM, Robert Widmann  wrote:
> 
> As I was saying, I agree with the overall usefulness of newtype-style 
> declarations, but I don’t understand why we need so much syntax for what 
> should just be a pattern in Swift.  Specifically, the idea of automatic 
> delegation of an interface is antithetical to the very reason why Haskell has 
> newtype in the first place.  And in the situations in which I would create an 
> alternate definition of a type, I expect to never inherit the interface of 
> the underlying type because I intend for it to be completely distinct. 

What would this pattern look like?

An alternative inherits nothing by default. You have to explicitly publish 
members from the underlying type to the current one. And you don’t have to; you 
can leave members out, or implement trampolines yourself. I wanted something 
between Go’s taking everything and C++’s taking nothing, more selectable like 
Haskell. (But I don’t really understand Haskell.)

> Additionally, the use of inheritance in alternate definitions seems out of 
> place and the casting section breaks encapsulation.

Enumerations use similar syntax to specify their raw type. What word, which may 
have to be new, should be used to serve a similar function as “super” within 
the main initializer?

Isn’t breaking (or at least bending) encapsulation a point of casting? And 
shorter than calling “rawValue” and/or “init?” a bunch of times?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

[Daryle Walker via swift-evolution]

> On Jul 31, 2017, at 1:49 PM, Robert Widmann <rwidm...@apple.com> wrote:
> 
>> On Jul 31, 2017, at 10:34 AM, Daryle Walker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Part of the response that closed [SR-5589] as “Won’t Do” was:
>> 
>>> AnyObject is no longer a protocol
>> 
>> 
>> Then, what is it?
> 
> Relevant https://github.com/apple/swift/pull/8749 
> <https://github.com/apple/swift/pull/8749> 

So… it got moved one layer down of indirection?

Hmm, what would this mean for a similar “protocol”? One that has a member 
attached. (My “strong type-alias” proposal has all such named types derived 
from an “AnyAlternative” protocol, which derives from “RawRepresentable” and 
adds another associated type.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Idea] Custom keywords for operators.

[Daryle Walker via swift-evolution]

> On Jul 31, 2017, at 5:09 PM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> So I was thinking the other day (and by "the other day" I mean "It just 
> occurred to me") that Swift's custom operator declaration mechanism is pretty 
> sweet (it's become even sweeter ever since numeric precedence values were 
> replaced with purely relativistic precedence trees). There are currently only 
> two problems with them that grind my operator-declaring endeavors to a 
> painful halt:
>   1. The fact that most punctuation characters on the keyboard (think - 
> ASCII) are reserved, so any custom operator either has to be a long sequence 
> of two or three non-reserved ASCII characters or have to include 
> difficult-to-type unicode punctuation characters.
>   2. The fact that anything that passes as an identifier character (which 
> includes a surprisingly wide array of punctuation characters) is off the 
> table as well.
> 
> I have no good idea how to deal with the first problem, but the second 
> problem seems to have a bafflingly simple solution that I can't believe I 
> haven't noticed until now.
> And the reason to even try to solve that problem is because Swift already has 
> a lot of operators with identifiers in them:
>   * infix is
>   * infix as
>   * infix as?
>   * infix as!
>   * prefix try
>   * prefix try?
>   * prefix try!
>   * prefix throw
> So this is hardly a new concept to Schwifty developers.

I think I read on some thread here that the sets of token sequences for 
identifiers and operators are deliberately distinct, so basic parsing agents 
can be made. This can’t be done in C++ because some tokens are too 
context-sensitive for anything less than a full parser; the Swift authors 
didn’t want this to happen here. The keyword operators you gave aren’t a 
general rule, but custom syntax. They work because the exception list is 
limited, and probably won’t be generally open.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

[Daryle Walker via swift-evolution]

> On Jul 31, 2017, at 1:33 AM, Daryle Walker  wrote:
> 
>> On Jul 31, 2017, at 1:19 AM, Xiaodi Wu > > wrote:
>> 
>> Daryle, this discussion has indeed taken place before. One good place to 
>> start is the Google result for "swift evolution non-conformance".
> 
> I added SR-5589, to request a counter protocol to AnyObject.

Part of the response that closed this as “Won’t Do” was:

> AnyObject is no longer a protocol


Then, what is it?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

[Daryle Walker via swift-evolution]

> On Jul 31, 2017, at 1:19 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> Daryle, this discussion has indeed taken place before. One good place to 
> start is the Google result for "swift evolution non-conformance".

I added SR-5589, to request a counter protocol to AnyObject.

> On Sun, Jul 30, 2017 at 5:30 PM, Daryle Walker via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
> > On Jul 30, 2017, at 5:03 PM, Tino Heth <2...@gmx.de <mailto:2...@gmx.de>> 
> > wrote:
> >
> >> [Apologies if this is in Swift 4 already.]
> >>
> >> We can have generic parameters match a protocol. But I have an idea in my 
> >> head that involves the type NOT conforming to a protocol. I don’t think we 
> >> have a way currently to work with this.
> > Why do you want that?
> > When something conforms, you know that you can call the methods of the 
> > protocol, but without conformance, you can't do anything that's not 
> > possible using "is".
> > Also:
> > Don't forget retroactive conformance — you can never rely on 
> > non-conformance.
> 
> I forgot about that last part. But my idea still has merit, due to why I 
> desired it in the first place.
> 
> The “AnyObject” protocol is marked on all class types. All class types 
> conform to it, and it’s illegal (as I understand it) to put on a type that 
> isn’t already a class. I have been working on a “strong type-alias” proposal, 
> and it has a similar protocol. And I came up with ideas that depend on a type 
> NOT being a strong type-alias. That’s what prompted the post. Note that these 
> protocols cannot be retroactively applied, so negation has merit.
> 
> Since there’s a limited number of them, a better solution could be to add a 
> “NeverAnObject” protocol that’s automatically slapped onto non-class types 
> (and cannot be added onto class types). And like “AnyObject,” it can be a 
> base protocol, but this time it forces the conforming protocol to not be for 
> classes.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Daryle Walker via swift-evolution]

The parameters for a fixed-size array type determine the type's size/stride, so 
how could the bounds not be needed during compile-time? The compiler can't 
layout objects otherwise. 

Or do you mean that the bounds are integer literals? (That's what I have in the 
design document now.)

Sent from my iPhone

On Jul 30, 2017, at 8:51 PM, John McCall <rjmcc...@apple.com> wrote:

>> On Jul 29, 2017, at 7:01 PM, Daryle Walker via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> The “constexpr” facility from C++ allows users to define constants and 
>> functions that are determined and usable at compile-time, for compile-time 
>> constructs but still usable at run-time. The facility is a key step for 
>> value-based generic parameters (and fixed-size arrays if you don’t want to 
>> be stuck with integer literals for bounds). Can figuring out Swift’s story 
>> here be part of Swift 5?
> 
> Note that there's no particular reason that value-based generic parameters, 
> including fixed-size arrays, actually need to be constant expressions in 
> Swift.
> 
> John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Jul 30, 2017, at 4:54 PM, Félix Cloutier  wrote:
> 
>> Le 29 juil. 2017 à 16:01, Daryle Walker  a écrit :
>> 
>>> On Jul 25, 2017, at 2:14 AM, Félix Cloutier via swift-evolution 
>>>  wrote:
>>> 
>>> It seems to me that I'm the one advocating for fewer language changes, and 
>>> the majority of sub-features that are being requested here don't feel 
>>> particularly more general to me.
>>> 
>>> In its current form, this proposal tackles a contentious syntax to declare 
>>> fixed-length arrays and a similarly contentious syntax to initialize them, 
>>> it has multi-dimensional arrays, unpacking of arrays as parameter lists, 
>>> zero-size types with alignment requirements, sized array literals, explicit 
>>> conversions between array types, rules for deterministic initialization, 
>>> vector types. Out of these, I could see parameter unpacking and vectors 
>>> used for more than fixed-size arrays. (I haven't been through the entire 
>>> discussion, though, so you might be able to point out a few more.)
>> 
>> On “unpacking of arrays as parameter lists,” are you talking about tuple 
>> conversion? That’s mainly to convert legacy C-conversions, which are 
>> manually homogenous tuples, to proper arrays. I added a little 
>> generalization instead of requiring a strict flat “(T, T, …, T, T)” format 
>> for the tuple type. If I didn’t need that legacy support, I probably 
>> wouldn’t have added tuple conversion at all.
> 
> No, I am talking about the `b[ [;1, 4] ]` syntax.

I didn’t have that at first. Later, I added “#indexOf”. That operator does not 
dump a bunch of comma-separated tokens; it returns a full object (a 
one-dimensional fixed-size integer array). To actually be usable in indexing a 
parallel array of the same shape, I needed to either explode the array to a 
comma-separated list of integers, or add a subscript operator that takes all 
the indexes as a single object. The second one seems easier, especially since 
“comma-separated tokens of some kind” isn’t a Swift entity (at least not yet).

>> So zero-size arrays should have no alignment requirements? Looking at a 
>> playground, empty tuples (both “()” and “((), ())”) have zero size but a 
>> stride of 1. Since elements of an array are spaced out by stride instead of 
>> size, what happens if an empty array is used as an element type. Zero-size 
>> arrays should take up at least a stride of 1, but if not rounded up to the 
>> element type’s alignment, then the array alignment won’t match the element 
>> alignment. These worries are why I initially banned empty arrays from being 
>> element types. Should I go back to that?

In the update I’m working on, empty arrays take no size when they’re 
sub-objects (in a structure, tuple, or fixed-size array), but a minimal size 
when they’re top-level objects (globals and function locals).

>> The proposal technically does not affect the rules for deterministic 
>> initialization. The only point of note is since FSAs are aggregate compound 
>> types, an instance's elements’ DI statuses are tracked separately, just like 
>> tuple members. Everything in the rest of that section, besides future 
>> suggestions, falls into place using the existing DI rules.
> 
> I was merely enumerating the entirety of the features that your proposal 
> requires to be implemented, as a response to Tino saying that I was 
> suggesting more features that were less general.
> 
>> Since FSAs are a new kind of type, new ABI entries need to be formed. A 
>> reason to mention vector mode now is that using a processor vector-unit type 
>> or not affects the implementation of a FSA, hence its ABI. I want to put all 
>> the parameters on FSA that could affect the ABI in at once, so we don’t have 
>> to propose another ABI change later. This definitely includes vector mode, 
>> and may include multi-dimensionality.
>> 
>>> There's also a number of issues that aren't addressed in the document, 
>>> which I feel are obscured by the sheer number of things that it asks to 
>>> consider: for instance, as we mentioned on another thread, Swift anonymous 
>>> types can't conform to protocols, so it's not clear what fixed-size arrays 
>>> have to be under the hood to be iterable.
>> 
>> Did you look over the document? There’s a whole section on element traversal.
> 
> Yes, there is a section on array traversal, but there is a difference between 
> saying "this needs to work" and "here's how it's going to work". If you're 
> looking for what I missed, that would be that fixed-size arrays are meant to 
> be their own special category of types, and not sugar on top of something 
> else.
> 
> Speaking of things that are not addressed in the document, then, would be 
> what any of this looks like at the SIL level. In fact, your proposal never 
> spells out "SIL”.

Because I don’t know that much about it. I know a little more about LLVM and 
the ABI; so their contributions to 

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

[Daryle Walker via swift-evolution]

> On Jul 30, 2017, at 5:03 PM, Tino Heth <2...@gmx.de> wrote:
> 
>> [Apologies if this is in Swift 4 already.]
>> 
>> We can have generic parameters match a protocol. But I have an idea in my 
>> head that involves the type NOT conforming to a protocol. I don’t think we 
>> have a way currently to work with this.
> Why do you want that?
> When something conforms, you know that you can call the methods of the 
> protocol, but without conformance, you can't do anything that's not possible 
> using "is".
> Also:
> Don't forget retroactive conformance — you can never rely on non-conformance.

I forgot about that last part. But my idea still has merit, due to why I 
desired it in the first place.

The “AnyObject” protocol is marked on all class types. All class types conform 
to it, and it’s illegal (as I understand it) to put on a type that isn’t 
already a class. I have been working on a “strong type-alias” proposal, and it 
has a similar protocol. And I came up with ideas that depend on a type NOT 
being a strong type-alias. That’s what prompted the post. Note that these 
protocols cannot be retroactively applied, so negation has merit.

Since there’s a limited number of them, a better solution could be to add a 
“NeverAnObject” protocol that’s automatically slapped onto non-class types (and 
cannot be added onto class types). And like “AnyObject,” it can be a base 
protocol, but this time it forces the conforming protocol to not be for classes.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Daryle Walker via swift-evolution]

> On Jul 30, 2017, at 5:34 PM, Tino Heth <2...@gmx.de> wrote:
> 
>> If you read my reply to Daniel Vollmer, you’ll find that we’re thinking 
>> about the exact same thing. 
> Good to hear — read that post later, but I guess repeating doesn't hurt here: 
> People still talk about macros... ;-)
> 
>>> So while I think they’re both great features to have, I assume the core 
>>> team will have higher priorities on their schedule, as I don’t see how 
>>> these features wouldn’t eat up most resources for at least (!) one Swift 
>>> release-cycle.
>> 
>> That’s just it: the core team is already prioritizing a lot of features that 
>> would greatly benefit from this. In fact, if this would be implemented, a 
>> large portion of the swift compiler could be moved into the standard 
>> library, because it wouldn’t be magic any more. This would single-handedly 
>> reduce the implementation time and effort of most proposals by a very large 
>> margin.
> 
> … and I like specific examples ;-), so out of my head, four features that 
> people want to have and that could be added easily with "Meta-Swift":
> - Forwarding of protocol conformance (Kotlin, for example, has this: When a 
> member conforms to a protocol, you don't have to write a bunch of methods 
> that just say "let my member do this")
> - init with reduced boilerplate
> - Subtyping for non-class types, including a "newtype" option
> - Property behaviours

The first and third items in that list seem similar to the “strong type-alias” 
idea I just updated (at 
). Is it 
close to what you’re talking about? I did the update because I recently looked 
up product and sum types again, and saw things called subtypes and quotient 
types. I realized that, with a little tweaking, strong-type-aliases could what 
would be needed to model sub- and quotient types.

> Imho the reflection capabilities that are needed to make the feature fly are 
> the big tasks — using this information shouldn't be that hard, as it's just a 
> explicit way of telling the compiler what to do.
> Assuming that reflection will be improved anyways, it might be a very cheap 
> feature with huge benefit.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

[Daryle Walker via swift-evolution]

[Apologies if this is in Swift 4 already.]

We can have generic parameters match a protocol. But I have an idea in my head 
that involves the type NOT conforming to a protocol. I don’t think we have a 
way currently to work with this.

In C++, templates can be specialized or partially specialized. Either 
specialization lets you define special code when the template parameters match 
the pattern. I realized that it can anti-match by putting your secret sauce in 
the general version of the template and leave the specialized version empty. 
But, AFAIK, we can’t specialize Swift generics (in the same way), so we’re 
stuck.

The change needs to be added to generic parameter conformance in parameter and 
where clauses. We should also support an anti-version for same-type 
requirements.

Now the question is what token (sequence) to use? For anti-conformance to 
same-type, I don’t see a reason to not use the obvious “!=“ choice. But what 
would be the opposite of the colon used in type/protocol matching? Would “!:” 
look dumb? Would we have to make sure a “T!” type expression isn’t against the 
“:” to prevent the parser from changing conformance to anti-conformance?

Would putting a “!” directly before the type/protocol to be matched (i.e. on 
the right of the colon) be better?

//=
Grammar of a Generic Parameter Clause

generic-parameter-clause → < generic-parameter-list >
‌generic-parameter-list → generic-parameter | generic-parameter , 
generic-parameter-list
‌generic-parameter → type-name
‌generic-parameter → type-name : !opt type-identifier
‌generic-parameter → type-name : !opt protocol-composition-type
‌generic-where-clause → where requirement-list
‌requirement-list → requirement | requirement , requirement-list
‌requirement → conformance-requirement | same-type-requirement
‌conformance-requirement → type-identifier : !opt type-identifier
‌conformance-requirement → type-identifier : !opt protocol-composition-type
‌same-type-requirement → type-identifier == type
‌same-type-requirement → type-identifier != type
//=

Where the fourth, fifth, ninth, and tenth productions add an optional “!”. And 
the last production is new (although with a misleading title).

…

Now reported at .

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Change 'for in' expression to for [] { (item) in ... }

[Daryle Walker via swift-evolution]

> On Jul 28, 2017, at 12:19 PM, Kwanghoon Choi via swift-evolution 
>  wrote:
> 
> Hello
> 
> I found someone easy mistake using for in loop statement.
> 
> Ex)
> var i = 0
> for i in 0..<10 { }
> print(i)
> 
> And this user expected print(i) is “10”
> 
> Many experienced swift developers doesn’t misunderstand like this. But always 
> someone is new comers, and I think this expression make misunderstand easy 
> too.
> 
> So why not like this?
> 
> var I = 0
> for 0..<10 { (i) in … }
> 
> I think this is more understandable for loop expression. 

Maybe a better change would be for every function not nested within another, 
all local variables (including the in-function name for parameters and the 
parameters/locals of nested functions) need to be uniquely named. (I think some 
obscure language I read about once does this.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Jul 25, 2017, at 2:14 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> It seems to me that I'm the one advocating for fewer language changes, and 
> the majority of sub-features that are being requested here don't feel 
> particularly more general to me.
> 
> In its current form, this proposal tackles a contentious syntax to declare 
> fixed-length arrays and a similarly contentious syntax to initialize them, it 
> has multi-dimensional arrays, unpacking of arrays as parameter lists, 
> zero-size types with alignment requirements, sized array literals, explicit 
> conversions between array types, rules for deterministic initialization, 
> vector types. Out of these, I could see parameter unpacking and vectors used 
> for more than fixed-size arrays. (I haven't been through the entire 
> discussion, though, so you might be able to point out a few more.)

On “unpacking of arrays as parameter lists,” are you talking about tuple 
conversion? That’s mainly to convert legacy C-conversions, which are manually 
homogenous tuples, to proper arrays. I added a little generalization instead of 
requiring a strict flat “(T, T, …, T, T)” format for the tuple type. If I 
didn’t need that legacy support, I probably wouldn’t have added tuple 
conversion at all.

So zero-size arrays should have no alignment requirements? Looking at a 
playground, empty tuples (both “()” and “((), ())”) have zero size but a stride 
of 1. Since elements of an array are spaced out by stride instead of size, what 
happens if an empty array is used as an element type. Zero-size arrays should 
take up at least a stride of 1, but if not rounded up to the element type’s 
alignment, then the array alignment won’t match the element alignment. These 
worries are why I initially banned empty arrays from being element types. 
Should I go back to that?

The proposal technically does not affect the rules for deterministic 
initialization. The only point of note is since FSAs are aggregate compound 
types, an instance's elements’ DI statuses are tracked separately, just like 
tuple members. Everything in the rest of that section, besides future 
suggestions, falls into place using the existing DI rules.

Since FSAs are a new kind of type, new ABI entries need to be formed. A reason 
to mention vector mode now is that using a processor vector-unit type or not 
affects the implementation of a FSA, hence its ABI. I want to put all the 
parameters on FSA that could affect the ABI in at once, so we don’t have to 
propose another ABI change later. This definitely includes vector mode, and may 
include multi-dimensionality.

> There's also a number of issues that aren't addressed in the document, which 
> I feel are obscured by the sheer number of things that it asks to consider: 
> for instance, as we mentioned on another thread, Swift anonymous types can't 
> conform to protocols, so it's not clear what fixed-size arrays have to be 
> under the hood to be iterable.

Did you look over the document? There’s a whole section on element traversal.

If you really want a Collection, and/or you want a Swift version of the “T[]” 
parameter interface from C where the argument can be an array of any length but 
a constant type, then use “withUnsafe(Mutable)Flattening”. If you want to 
iterate without converting to a Collection first, then you can use a FSA as the 
target of a “for-in” loop directly. If you need the iteration counter during 
the for-loop, a spiritual equivalent to Collection’s “enumerated," then use the 
new “#indexOf” primary expression.

Iteration order of a FSA during a “for-in” loop is unspecified. That’s because 
I want to allow the compiler to pick what it thinks is the best order (which 
may not be storage order (but probably would be)). And I want to allow the 
compiler to use simultaneous (or other overlapping) orders. And that previous 
point is to allow processor vector-unit types as FSA implementations.

> Of course, if you take all of that, that's possibly bigger than non-type 
> generic parameters, but I question whether it all needs to pass at the same 
> time, or even if there are things that could be dropped to make this more 
> manageable.

I already have dropped some things. Not sure how much I can trim down and keep 
Version 1 of FSAs useable.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Jul 24, 2017, at 7:29 AM, Tino Heth <2...@gmx.de> wrote:
> 
> Also, I might have a different focus for the feature:
> Performance and C interoperability are important, but I just want type safety 
> and to avoid creating stupid things like Vector3, Vector4… which can't share 
> code because there's no inheritance for structs (yet), and which are limited 
> in expressiveness.
> 
> I don't think arrays should be multidimensional: Memory has only one 
> dimension, this is a low level feature — and it's easy to build 
> multi-dimensional structures on top of simple arrays.

K in their original C decided to make arrays a low-level type, are removed 
the mid-level features other languages had for their arrays. I’m deciding in 
the opposite direction, allowing FSAs to be mid-level types, and adding (back) 
features appropriately.

Also, a core goal of FSAs is a user gateway to processor vector-unit types, and 
I didn’t want to ban 2D vector unit types (if they exist).

> I also have little need for a special syntax for literals: When the array is 
> used as communication medium ("this function returns an array of size 3"), 
> I'm not using literals at all, and when I'm declaring a array for my own use, 
> I wouldn't mind if the compiler decides on his own that it can be fixed size.
> There's also the use case of creating an array that will be handed over to a 
> method that expects a FSA, but I wouldn't mind if I have to declare the type 
> explicitly in this case.

I originally used standard array literals for FSAs. And other people complained 
about that!

The problem is that the only way to know if an array literal is supposed to go 
to a FSA instead of an instantiation of Array is the surrounding context. And 
some people didn’t like that; they wanted the type to be (almost) always 
determined by the literal alone. In the old way, I needed a “let x: [_: Int] = 
[1, 2, 3, 4]” wildcard construct to allow automatic determination of the 
length. By including the array shape, we can differentiate FSAs from Array.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Jul 23, 2017, at 11:20 PM, Taylor Swift  wrote:
> 
> On Sun, Jul 23, 2017 at 11:05 PM, Daryle Walker  > wrote:
> 
>> On Jul 23, 2017, at 12:04 PM, Taylor Swift > > wrote:
> 
>> 
>> Incomplete indexing means 
>> 
>> let fsa:[5, 2; Int] = [5, 2; 2, 4, 3, 5, 4, 6, 5, 7, 6, 8]
>> fsa[3] // [2; 5, 7]
>> 
>> this would be the same as writing 
>> 
>> let fsa:[5; [2; Int]] = [5; [2; 2, 4], [2; 3, 5], [2; 4, 6], [2; 5, 7], [2; 
>> 6, 8]]
>> fsa[3] // [2; 5, 7]
>>  
>> in your current system. This would obviate the need to nest FSAs for the 
>> purpose of extracting entire rows of data.
> 
> Allowing partial indexing as you show it privileges one dimension over the 
> others, although they’re supposed to be co-equal and the reason a particular 
> dimension is privileged is due to an implementation detail. Or would you 
> allow incomplete indexing on other dimensions besides the first? Where the 
> true-multi-dimensional <-> nested FSA equivalence wouldn’t help you (because 
> the elements are dispersed in the whole array). With complete generics, this 
> could be a library function:
> 
> func removeRow(array: […M, P, 
> …N; T], row: Int) -> […M, …N; T] where #lengthof(M) == Dimension
> 
> 
> I’m confused as to what the goals of FSAs are here. My understanding is that 
> they are supposed to be a very low-level high-performance type that’s closely 
> linked with the underlying memory representation. That’s why memory order 
> initialization and flattened indexing is allowed, isn’t it? Partial indexing 
> privileges one dimension over the others, precisely because one dimension 
> should be privileged over the others, because it is much faster than a column 
> slice. The partial indexing syntax is good because it emphasizes that this is 
> an inherently fast operation. Whereas arbitrary row extraction should be a 
> special function to emphasize that it is an inherently slow operation.

My vision of FSAs is as a low-ish mid-level type, not a low-level type and 
definitely not a very-low-level type. Yes, use as implementing parts of an 
abstract data type is a goal, otherwise why not stick with Array. And 
performance is a goal. But FSAs should be usable outside of that. That’s one 
reason my FSAs support multiple dimensions; it’s the opposite of K’s decision 
throwing out multiple dimensions in the original C when its contemporaries had 
them.

[Another reason for default support for multiple dimensions is that I don’t 
know if any processor vector-unit types model 2D arrays, or if all are 1D 
vectors. Limiting FSAs to one dimension means there’s no easy way to model 2D 
vector-type arrays. Using FSAs to bring processor vector-unit types to the user 
level is a core goal.]

Memory-order initialization for multi-dimensional arrays when not using 
explicit indexes is to save on needing to type out said indexes. And to help 
inform what elements are which when using static indexing. (Static indexing is 
flattened because my first attempt at making a multi-coordinate version of 
tuple’s anonymous member access looked dumb.)

By flattened indexing, do you mean the "withUnsafe*Flattening” functions? Those 
give the users a way to access the array as a collection. And it’s a way to 
handle functions that want an array of a particular element type, but for any 
length/shape, an adaptation of the “T[]” parameter type in C functions. The 
“T[]” parameter type let C programmers write a function for any array segment 
length, without specializations for “T[1],” “T[2],” “T[3],” and so on. (You 
have to pass the actual length separately.) This was before C++ templates and 
allowing function specializations per array length, but using the “T[]” saves 
on how many specializations are needed (just one instead of per array length 
used).

If you mean the “for-in” loop, the flattening is meant to be an abstraction. 
The C-style for loop was removed because we now abstract the iteration over 
collections so you don’t have to manually maintain an iteration counter. The 
flat for-loop removes having to manually write loop statements per dimension. 
If you don’t need the iterator-counter/iteration-coordinate, skipping the need 
to write the counter(s) anyway is a big savings. The new problem is what to do 
when you do want the iteration counter(s). For collections, use the 
“enumerated” method, which just returns a new sequence that is a pair of the 
original element and the would-have-been iteration counter. For FSAs, since 
iteration order is unspecified and copying to a bigger array is impractical, I 
use a new primary expression to get the counter.

To have partial indexing, and keep it only to the first (i.e. outermost) 
dimension, we can add a new set of global functions:

func withUnsafePartialIndexing(of arg: inout [M, 
…N; T], _ body: (UnsafeBufferPointer<[…N; T]>) throws -> 

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Jul 24, 2017, at 1:22 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
> Do FSAs really need special sugar, though? They won’t be an extremely 
> heavily-used construct, but rather they’ll be occasionally used either for 
> performance reasons or to interact with C APIs. Sure, C had a short syntax 
> for making them, but making pointers in C was short, too, and that hasn’t 
> been carried over into Swift. In fact, a FSA has a lot in common with an 
> UnsafeBufferPointer that you don’t have to worry about deallocating. 
> Furthermore, there are collection types such as Set and ContiguousArray which 
> are arguably more useful than FSA, yet don’t have their own syntax.
> 
> Is this really not good enough?
> 
> let arr = FixedArray(capacity: x)

Yes, it’s not good enough. This looks like it would be a struct in the standard 
library. And named types have at least one initializer, and one of which must 
be called during non-assignment initializations. But named types must be 
completely initialized by the time any initializer ends, and that’s a non-goal 
for FSAs. My FSA design uses compound types so we can initialize in piecemeal. 
(We could suspend complete initialization for these static named array types, 
but that inconsistency would be a “cure worse than the disease” solution.)

Also, this looks like the array bounds are determined at run-time, requiring 
remote storage, which is an anti-goal. One of the main goals of FSAs is to use 
scoped storage (unlike Array) with easy indexing (unlike tuples). Newer 
versions of C have a function to dynamically use scoped storage, so we could 
use that, but we usually know what array shape we need at compile-time, so why 
move the decision to run-time? And dynamically determined scoped storage would 
screw up use as sub-objects.

If it’s not a named type, but a compound type with named-type-looking syntax, 
it’s too much of an anti-sugar solution.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Planning][Request] "constexpr" for Swift 5

[Daryle Walker via swift-evolution]

The “constexpr” facility from C++ allows users to define constants and 
functions that are determined and usable at compile-time, for compile-time 
constructs but still usable at run-time. The facility is a key step for 
value-based generic parameters (and fixed-size arrays if you don’t want to be 
stuck with integer literals for bounds). Can figuring out Swift’s story here be 
part of Swift 5?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch] Update to Alternative Types (i.e. strong typedef) Proposal

[Daryle Walker via swift-evolution]

Proposal at 
, uploaded 
revision 4.

Changes:

Since the original setup was a poor copy of how raw-style enumerations use 
RawRepresentable, changed the model to actually use RawRepresentable. Actually, 
it uses a sub-protocol, AnyAlternative, which adds an associated type for the 
implementing non-alternative type. AnyAlternative also serves a function like 
AnyObject.
Removed the old library support type since it’s obsolete. Added back a (now 
global) function to upcast to the implementation type without needing to name 
it.
Added option to initialize alternative by assigning to “super.” Using “super” 
by itself isn’t allowed in the grammar (It has to be followed by a member 
specification), so I added it.
Added note about pointer compatibility.
The model change led to a lot of rewording. And new/changed technical terms.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] Why couldn't a class call any of its superclass' initializers?

[Daryle Walker via swift-evolution]

[Sorry if this's been discussed before.]

As long as the superclass sub-object gets initialized, it shouldn't matter if 
the initializer was designated or convenience. Is there some subtle step on the 
two-phase initialization I'm missing? Or is this a point to extend in a future 
version of Swift?

Sent from my iPhone
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Jul 23, 2017, at 3:18 PM, Taylor Swift via swift-evolution 
>  wrote:
> 
> 
> If we’re actually going to try and establish a relationship between the FSA 
> asterisk and the multiplication asterisk, this is even more problematic. How 
> does the asterisk work in FSA literals, where there is no type annotation to 
> go on the right of the asterisk? 
> 
> Also introducing contextual keywords like “of” is going to cause a huge 
> amount of problems with syntax highlighters considering how often the word 
> “of” is used as an argument label in Swift. The words “as” and “stride” 
> already make for some interesting code highlighting, “of” would take it to a 
> whole new level.

I think I mentioned it at the end of the proposal, but there’s a reason I’m 
using comma/colon/semicolon for FSAs. They are already reserved separators 
within Swift’s syntax. The multiplier ideas or “of” seem to be just for 
cuteness; why take a token out from being free to reserved for a purpose that 
can be mechanically done by an existing separator token.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Jul 23, 2017, at 12:04 PM, Taylor Swift  wrote:
> 
> 
> 
> On Sun, Jul 23, 2017 at 3:08 AM, Daryle Walker  > wrote:
> 
>> 9. I don’t see the value in having both nested FSAs and multi-dimensional 
>> FSAs. Aren’t they the same thing? For example, in the code snippet
> 
> Why does any language with multi-dimensional arrays (like Fortran or Ada) 
> have them? By this standard, no language should have multi-dimensional 
> arrays. They exist because of data modeling. Co-equal coordinates in the 
> model should be co-equal in their representation in the program. Yes, they 
> are implemented the same way underneath. We don’t copy C everywhere, so why 
> not take this opportunity to do better. Also, just using nesting could imply 
> that the intermediate array types have a meaning, but they might not if 
> they’re just implementation quirks and not part of the abstract model.
> 
> Nested arrays are not my solution for multi-coordinate indexing; use 
> multi-dimensional arrays for that. I mention nested arrays because:
> 
> Nested arrays fundamentally cannot be banned. (What if an element type is 
> hidden behind a type-alias and is conditionally an array type?)
> Doesn’t Swift have to resolve the types at some point anyway? If it’s 
> impossible to ban, we can allow it, but still make it unidiomatic. Nested 
> arrays are much messier to write than multidimensional arrays.

The new draft I’m writing downplays nested arrays a lot. They’re mentioned in 
the section discussing the core element type (nee the inner non-array type).

> I need the definition to explain the “inner non-array type”
> I need the inner non-array type to explain which pairings of FSAs for 
> reshaping are legal. (And a similar reason for tuple conversion.) Note the 
> two types can have different nesting levels.
> I need to explain that empty arrays cannot be an array element type. (Should 
> this be changed? What happens with tuples or structures containing empty 
> tuples/structures as members? What about empty tuples/sturctures in “Array”? 
> Banning empty arrays means we don’t have to worry about every array element 
> being at the same address. The other way to solve this is to make them one 
> byte (or word) long.)
> 
>> ```
>> let a = [;1, 2, 3, 4]
>> assert(a[0] == 1)
>> assert(a[1] == 2)
>> assert(a[2] == 3)
>> assert(a[3] == 4)
>> let b = a as [2, 2; Int]
>> assert(b[0, 0] == 1)
>> assert(b[0, 1] == 2)
>> assert(b[1, 0] == 3)
>> assert(b[1, 1] == 4)
>> let c = a as [2; [2; Int]]
>> assert(c[0][0] == 1)
>> assert(c[0][1] == 2)
>> assert(c[1][0] == 3)
>> assert(c[1][1] == 4)
>> ```
>> 
>> There’s three syntaxes which accomplish two unique things. I lean towards 
>> disallowing FSA nesting and instead allowing incomplete index lists to 
>> partially unnest multidimensional FSAs. Let’s reserve “[][][]...” for 
>> flexible array chained dereferencing.
> 
> I don’t understand what your incomplete index list idea is. And as I said, 
> the chaining technique is less I desire it and more I can’t ban it and keep 
> Swift features orthogonal.
> 
> Incomplete indexing means 
> 
> let fsa:[5, 2; Int] = [5, 2; 2, 4, 3, 5, 4, 6, 5, 7, 6, 8]
> fsa[3] // [2; 5, 7]
> 
> this would be the same as writing 
> 
> let fsa:[5; [2; Int]] = [5; [2; 2, 4], [2; 3, 5], [2; 4, 6], [2; 5, 7], [2; 
> 6, 8]]
> fsa[3] // [2; 5, 7]
>  
> in your current system. This would obviate the need to nest FSAs for the 
> purpose of extracting entire rows of data.

Allowing partial indexing as you show it privileges one dimension over the 
others, although they’re supposed to be co-equal and the reason a particular 
dimension is privileged is due to an implementation detail. Or would you allow 
incomplete indexing on other dimensions besides the first? Where the 
true-multi-dimensional <-> nested FSA equivalence wouldn’t help you (because 
the elements are dispersed in the whole array). With complete generics, this 
could be a library function:

func removeRow(array: […M, P, …N; 
T], row: Int) -> […M, …N; T] where #lengthof(M) == Dimension


> 
>> 11. This should have defined behavior:
>> 
>> let data = [2, 2; 1, 2, 4, 8]
>> for (i, x) in data.enumerated()
>> {
>> total += x
>> }
> 
> FSAs are compound types, not named types, so there are no methods. (Just like 
> tuples, FSAs don’t follow any protocols.) But since they’re a built-in, I can 
> customize the “for-in” loop to cover all the elements in an 
> implementation-optimized order. (The implementation has the option of 
> multi-threading if it can see there’s no cross-iteration contamination.) 
> Since you can’t control the order without manual looping, the “#indexOf” 
> expression exists to let you know where you are during an iteration loop.
> 
> I first used the iteration variable as the operand to “#indexOf” to determine 
> which array instance to track. Then I saw that the for-loop implements its 
> iteration variable as a pattern in the 

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Jul 23, 2017, at 2:07 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> I think fixed-size arrays should be a nominal type like any other. They 
> should be able to have methods, conform to protocols, be extended with new 
> behavior, and generally present a user-experience similar to what arrays 
> already have. In particular, they should conform to Collection and to 
> ExpressibleByArrayLiteral.

Nominal types have to be completely initialized in their initializer, and I 
don’t think that should change. But we want to allow arrays to start off 
uninitialized, instead of a blanket initialization that would be paved over by 
the real initial data. That’s one reason FSAs are compound types. Another 
reason is that they’re kind-of low level, like tuples.

As I said in some other responses, the solution to slapping 
methods/protocols/other-new-interfaces to compound types is to make a strong 
type-alias of that type and add your interface there. (Once we have strong 
type-aliases, of course.)

I have fixed-size arrays to be compound types because 

> If we are going to use semicolons at all, it should be to demarcate the rows 
> of a 2-dimensional array, as that will be one of the most common use-cases:
> 
> let identity3x3: [Int(3, 3)] = [1, 0, 0;
> 0, 1, 0;
> 0, 0, 1]

That doesn’t seem scalable to higher dimensions.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

[Daryle Walker via swift-evolution]

> On Jul 23, 2017, at 7:27 PM, Félix Cloutier  wrote:
> 
> I think I've already said that, but I agree that an incremental approach to 
> this would be better.
> 
>> Le 23 juil. 2017 à 15:57, Chris Lattner  a écrit :
>> 
>> On Jul 22, 2017, at 3:03 PM, Daryle Walker  wrote:
 In my opinion, there is an easy three step plan :-) to solving this 
 problem, riffing on Array:
>>> 
>>> Well, fixed-size arrays don’t have initializers, for the same reason tuples 
>>> don’t: they’re compound types instead of named types and they literally 
>>> have nowhere to place initializer definitions. But like tuples, FSAs have a 
>>> literal syntax that works as a substitute for full-blown initializers.
>> 
>> Ok, sure.  They aren’t literally initializers in the stdlib (they are built 
>> into the compiler), but they have initialization semantics and can be 
>> spelled in whatever way makes ergonomic sense.  Keeping them aligned with 
>> Array seems like a good starting point.
> 
> Either way, in the context of fixed-size arrays, I think that it's a broader 
> problem that anonymous types can't have anything attached to them. This also 
> prevents fixed-size arrays from conforming to protocols, even Sequence, and 
> Swift would need variadic generics or (possibly, depending on the syntax) 
> non-type generic parameters to even create a wrapper.

My solution to tuples and fixed-size arrays not supporting attached interfaces 
is to make a strong type-alias to the compound type and add your interface 
there. And unlike alternatives added to the core language level, users who 
don’t want that particular extended interface (or want an incompatible one!) 
don’t have to live with it. It’s part of the “alternative types” proposal.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

> On Jul 23, 2017, at 5:49 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
> On Jul 23, 2017, at 12:18, Taylor Swift  > wrote:
> 
>> I don’t think tuples are a suitable replacement for FSAs. A tuple should be 
>> able to be broken up and optimized by the compiler, and have no contiguity 
>> guarantees in memory.
> 
> 
> C's static arrays are imported as tuples, which need at least some level of 
> contiguity guarantees to work. Even if tuples in general make that such a 
> guarantee, tuple-based FSAs could use the same compiler logic as imported C 
> arrays.

I think that’s supposed to be a workaround solution, not a map going forward. 
By having to support C-array conversion, tuples have to give up tuple-specific 
optimizations, like rearranging members and contiguity. Adding FSAs (with a 
distinct internal representation) will let the two have different optimizations.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

ke 
tuples, FSAs don’t follow any protocols.) But since they’re a built-in, I can 
customize the “for-in” loop to cover all the elements in an 
implementation-optimized order. (The implementation has the option of 
multi-threading if it can see there’s no cross-iteration contamination.) Since 
you can’t control the order without manual looping, the “#indexOf” expression 
exists to let you know where you are during an iteration loop.

I first used the iteration variable as the operand to “#indexOf” to determine 
which array instance to track. Then I saw that the for-loop implements its 
iteration variable as a pattern in the grammar instead of something simpler. 
And what happens if a wildcard is used as the iteration variable? And would 
people question why when the pattern has multiple iteration variables, all are 
equally valid for “#indexOf”? I moved the operand to be the label because we 
usually don’t have multiple labels on statements (Is that even legal in Swift?) 
and can optimize which loops need to be indexable.

> “with” methods should be used sparingly and not be part of common idioms like 
> iterating through an array as a buffer.

I need some library function to convert a FSA into a Collection, and to 
represent the “T[]” function parameter type concept from C, which represents 
any array size (instead of being locked for one length, or since we have 
multi-dimensional arrays, one shape). For safety, the callback function uses 
the buffer version so you have a pointer and size. You generally should be 
using the for-loop, though.

Using an unsafe buffer pointer forces the data into addressable memory, which 
isn’t necessarily the case of an instance’s location by default. (C optimizes 
the other way. Objects are addressable by default, and that is disabled, and 
any optimizations by being un-aliased activated, by the “restrict” qualifier.)

We should have some way to cull specific indexes in loops. (Like “lock index 2 
to column 5 but iterate over all the qualifying subset of elements.”) I don’t 
know if this has to be a new base operation on a loop, or if it can be done 
through a library function, or if it can be done through a library function 
after we complete generics. But I think it can wait until version 2.

> 12. Can we rename the `cardinality` type property to `nestingCount` or 
> `nestingLevels` something similar? That seems a lot clearer and more 
> descriptive of that the property actually represents. I’d also bet that close 
> to no one knows what cardinality is.

The nesting-level is “layers.” “Cardinality” is the number of co-equal 
coordinates. But that second name probably needs some work, although it can be 
synthesized from the length of “dimensions.” The “cardinality” and 
“elementCount” properties work around us not having (integer) compile-time 
constants yet; otherwise we can derive them from compile-time expressions on 
“dimensions."

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

> On Sat, Jul 22, 2017 at 3:41 PM, Daryle Walker via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> It’s at <https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb 
> <https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb>>.
> 
> * Try to clarify that fixed-size arrays are a new kind of compound type, not 
> a (ridiculously magical) library generic type.
> * Change the separator between the bounds and element type from a colon to a 
> semicolon.
> * Specify that violating the bounds of an array during indexing is a run-time 
> error.
> * Reword how the mapping of static-indexing elements for multi-dimensional 
> arrays works.
> * Completely redo array values/literals. A literal for a fixed-size array 
> always includes a semicolon, which separates the bounds from the values. (The 
> separator in FSA types was changed to a semicolon to match.) A value can be a 
> plain expression or a dictionary expression where the right side of the colon 
> is the value and the left side is the index of the target element or 
> “default” for all un-targeted elements. The left side can also be “func”, 
> with the right side being an initialization closure.
> * Move the “Reshaping Arrays” section and add an example.
> * Right now, deterministic initialization is unchanged, so an initializing 
> loop has to be changed to initializing the array with a function term, moving 
> the loop to the closure.
> * Remove the “parallel” declaration attribute. Add a future note about it and 
> the “fragmentary” attribute.
> * Change the for-loop example to conform to deterministic initialization. 
> Reword how the flattening buffer functions work.
> * Add examples to element-wise casting.
> * Reword tuple conversion section, and add an example.
> * Reword various vector-mode attribute secti

[swift-evolution] [Pre-pitch] "common" fields for union-style enumerations?

[Daryle Walker via swift-evolution]

Way back in the macOS pre-X days, I remember some APIs had types like:

struct Sample1 {
int a;
int b;
float c;
};

struct Sample2 {
int a;
int b;
double d;
};

The types are supposed to be related, and it was supposed to be guaranteed that 
if you type-punned Sample1 to or from Sample2, the common members (“a” and “b” 
here) would have the same semantics. I guess it could be done like this:

struct Sample {
int a;
int b;
union {
float c;
double d;
}
};

too.

I wonder if we need something similar in Swift:

enum Sample {
@common case withFloat(a: Int, b: Int, c: Float)
@common case withDouble(a: Int, b: Int, d: Double)
}

The attribute would ensure that the shared initial members would map to the 
same internal offset. And, if there were no cases that didn’t have the common 
members, you can use them as instance level properties:

var x: Sample = .withFloat(1, 2, 3.0)
//…
assert(x.a == 1)  // Instead of “x.withFloat.a"

Good idea? Does this already exist?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

[Daryle Walker via swift-evolution]

> On Jul 22, 2017, at 3:02 PM, Chris Lattner <clatt...@nondot.org> wrote:
> 
> On Jul 18, 2017, at 1:00 PM, Daryle Walker via swift-evolution 
> <swift-evolution@swift.org> wrote:
>>> On Jul 17, 2017, at 3:26 AM, Félix Cloutier <felix...@yahoo.ca> wrote:
>>> 
>>> I think that you're getting ahead of yourself. Fixed-size arrays are still 
>>> useful even if they have to have been demonstrably initialized before you 
>>> can use dynamic indices with them. A ton of people have already gotten into 
>>> the habit of writing `int foo[40] = {}` in C.
>> 
>> The person with the initial suggestion regrets this habit and deliberately 
>> doesn’t want it. In other words, don’t support the waste of cycles to 
>> pre-initialize just for the elements to be immediately paved over with the 
>> real initial data. And we may make arrays of types that are heavy to 
>> initialize and may not have a default initializer, so even using a 
>> default-value term at declaration will lead to a big waste of cycles.
>> 
>> We eventually have to decide how to modify deterministic initialization. Do 
>> we take the safe path with dynamic deterministic initialization (and add 
>> extra resources)? Or the fast path with suspension of checks (and risk 
>> undefined behavior)? We’re probably going to lean toward the former, 
>> especially since we can limit its scope (and therefore cost).

Oh, I just posted that I just updated my proposal before I saw this in my 
in-box.

> In my opinion, there is an easy three step plan :-) to solving this problem, 
> riffing on Array:

Well, fixed-size arrays don’t have initializers, for the same reason tuples 
don’t: they’re compound types instead of named types and they literally have 
nowhere to place initializer definitions. But like tuples, FSAs have a literal 
syntax that works as a substitute for full-blown initializers. My recent update 
made FSA-literals distinct from standard array literals.

Should there be an equivalent to “ExpressibleByArrayLiteral” for 
multi-dimensional literals? I don’t know, but it could wait for version 2.

> 1) Fixed size arrays should have an initializer to init all the elements to 
> some concrete value.

let a = [4; default: “whatever”]  // [4; String]

> 2) They should have an init that takes a closure, and runs it once per 
> element, passing in the index.

let b = [2, 3; func: { Double($0.0 * $0.0 + $0.1 * $0.1) }]  // [2, 3; Double]

The index, “$0” here, is passed as “[2; Int]”.

> 3) Either through a magic value or a third initializer, it should be possible 
> to *explicitly* create a fixed size array with uninitialized garbage for the 
> elements.  This is important for specific optimizations, and should also come 
> to Array as well.

let c = [6; 1, 2, 3]  // [6; Int], last 3 elements uninitialized

Obviously, the literal can’t use a “default” or “func” term if you want to keep 
some elements uninitialized.

Leaving elements uninitialized is a big reason for leaving FSAs compound types. 
We should not violate the expectation that an initializer (which named types 
have) leaves all sub-objects initialized. So I’m against adding this feature to 
Array, unless you mean something like “size” vs. “capacity” in C++’s vector and 
you need to call something like “push_back” to add an element instead of 
directly using subscript. Since a FSA is a compound type, its sub-objects’ 
states are tracked with deterministic initialization, just like tuple members.

> IMO, it isn’t a problem that C allows arrays to be uninitialized - the 
> problem is that it is a really bad default.

I was struggling which way to go; add run-time deterministic initialization or 
allow undefined behavior. For now, it’s neither; the current compile-time 
deterministic initialization has to be followed. But compile-time DI isn’t big 
a setback as long as you have all the information you need to set every element 
before initialization-assignment (with a function term).

I read a post once wishing for a function to join tuples together as a giant 
tuple. I was wondering about the same thing for FSAs, where you have to specify 
which index you want to be the axis of the join (and all the non-axis 
dimensions have to have corresponding lengths being equal). This requires more 
advanced generics than we have now; but if implemented, we could build arrays 
in piecemeal then join them together for the final value. It could look like:

let d = joinArrays<2>( [2, 3, 7, 5, 9; default: 23], [2, 3, 4, 5, 9; func: { 
$0.0 + $0.4 }] )  // [2, 3, 11, 5, 9; Int], axis 2: 7 + 4 == 11

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch] New Version of Array Proposal

[Daryle Walker via swift-evolution]

It’s at >.

* Try to clarify that fixed-size arrays are a new kind of compound type, not a 
(ridiculously magical) library generic type.
* Change the separator between the bounds and element type from a colon to a 
semicolon.
* Specify that violating the bounds of an array during indexing is a run-time 
error.
* Reword how the mapping of static-indexing elements for multi-dimensional 
arrays works.
* Completely redo array values/literals. A literal for a fixed-size array 
always includes a semicolon, which separates the bounds from the values. (The 
separator in FSA types was changed to a semicolon to match.) A value can be a 
plain expression or a dictionary expression where the right side of the colon 
is the value and the left side is the index of the target element or “default” 
for all un-targeted elements. The left side can also be “func”, with the right 
side being an initialization closure.
* Move the “Reshaping Arrays” section and add an example.
* Right now, deterministic initialization is unchanged, so an initializing loop 
has to be changed to initializing the array with a function term, moving the 
loop to the closure.
* Remove the “parallel” declaration attribute. Add a future note about it and 
the “fragmentary” attribute.
* Change the for-loop example to conform to deterministic initialization. 
Reword how the flattening buffer functions work.
* Add examples to element-wise casting.
* Reword tuple conversion section, and add an example.
* Reword various vector-mode attribute sections. Note that there need to be two 
ABI additions for FSA, one for non-vectorized FSAs and one for vectorized FSAs. 
These two kinds of arrays need conversion functions at our (i.e. the ABI) 
level, but are transparent for the user.

let v1: @vector [3; Int] = [; 1, 3, 5]
let v2: [3; Int] = v1  // Not a type-mismatch error

* Due to FSA’s literals including the bounds, or using automatic bounds mode, 
array-placeholder syntax is not longer needed for type annotations and has been 
removed.
* Renamed “nestings” to “layers”.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

[Daryle Walker via swift-evolution]

> On Jul 17, 2017, at 3:26 AM, Félix Cloutier  wrote:
> 
> I think that you're getting ahead of yourself. Fixed-size arrays are still 
> useful even if they have to have been demonstrably initialized before you can 
> use dynamic indices with them. A ton of people have already gotten into the 
> habit of writing `int foo[40] = {}` in C.

The person with the initial suggestion regrets this habit and deliberately 
doesn’t want it. In other words, don’t support the waste of cycles to 
pre-initialize just for the elements to be immediately paved over with the real 
initial data. And we may make arrays of types that are heavy to initialize and 
may not have a default initializer, so even using a default-value term at 
declaration will lead to a big waste of cycles.

We eventually have to decide how to modify deterministic initialization. Do we 
take the safe path with dynamic deterministic initialization (and add extra 
resources)? Or the fast path with suspension of checks (and risk undefined 
behavior)? We’re probably going to lean toward the former, especially since we 
can limit its scope (and therefore cost).

> I would like to encourage you to exercise your sense of priority and figure 
> out the minimum changes that you need to make to the language to get 
> something useful, without blocking avenues for expansion. I think that 
> everyone, especially the people that you would be signing up for a tremendous 
> amount of work with your current direction, will be happier this way.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] Array full proposal

[Daryle Walker via swift-evolution]

> On Jul 13, 2017, at 7:32 PM, Daryle Walker  wrote:
> 
 3) Default initialization semantics for arrays including a DI exception 
 for fixed-length arrays that aren’t fully initialized 
>>> 
>>> My first thought was full initialization, like other objects, but someone 
>>> on the list really wanted a way to not have full initialization. I could 
>>> see his point; filling in a bunch of zeros for a large array for math 
>>> purposes could get expensive, especially if the values are immediately ran 
>>> over. Even if we make closure-initialization return non-optionals, we still 
>>> have to worry when an array is filled by a loop that gets exited early.
>> 
>> As long as you have this magical type, you should probably give it some 
>> magical methods.  A “backfill” initializer, perhaps.  We cannot break DI 
>> just because it’s syntactically inconvenient.
>> 
> 
> There’s already the “default” term in extended array literals. And the “func” 
> term allows the elements to be determined via closure.
> 
> For DI, it’s worse than you think, which is why I put out a separate post on 
> this issue. DI assumes one sub-declaration per sub-object; the raison de-tere 
> for arrays is to defeat this assumption. DI and FSAs are fundamentally 
> incompatible; something has to break (forced initialization on declaration, 
> static array indexing, run-time DI, or undefined behavior on possible 
> uninitialized reads).

In a response to that separate post, I chose run-time DI for local objects and 
stored instance properties (the checks happen within each designated 
initializer), and one-shot initialization otherwise.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

[Daryle Walker via swift-evolution]

> On Jul 13, 2017, at 1:41 PM, Daryle Walker via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> As I understand it, Definitive Initialization means the Swift compiler will 
> make sure an instance is fully initialized before the first attempt to read 
> it. It does not require mandatory assignment at declaration; an instance can 
> be declared with no initializer and receive an assignment at a later point.
> 
> * Class and structure types are considered OK by DI when an initializer is 
> called.
> * Enumerations can either use an initializer or have an enumeration-case 
> assigned for DI.
> * Compound types (function pointers and tuples) use assignment (possibly at 
> declaration) for DI.
> * Tuples can also have the individual members can be tracked for DI. A member 
> has to be initialized by the time that member or the entire tuple is read 
> (whichever comes first).
> 
> Tuples (and the other types) can statically determine when a sub-object is 
> initialized. When adding a new member, via new text in the source code, a 
> corresponding new line(s) of code has to be added during the initialization 
> sequence. But built-in arrays, no matter how they’re defined, would be 
> different. The whole point of arrays is to allow adjustment the number of 
> sub-objects without per-sub-object alteration to the array type’s declaration 
> code. That means you can’t write out all the member initializations in 
> advance (in general). And that means you generally use a loop and 
> subscripting instead. And since that moves the references to which elements 
> get initialized to run-time, we have a fundamental incompatibility with 
> definitive initialization. (The fixed-size array proposal I recently posted 
> about does have a static indexing mode, but the point I’m making here is that 
> it doesn’t scale from the perspective of the regular array interaction model.)
> 
> Besides banning fixed-size arrays forever and ever (which just hides the 
> problem), we’re limited to:
> * Mandatory assignment at declaration, and the initializing expression has to 
> cover all elements
> * If arrays keep a static indexing mode, apply DI to an array instance using 
> that. This would mean changing the initialization sequence code every time 
> the number of elements is adjusted. And the initialization would have to be 
> from the static indexing mode for DI to recognize it (i.e. always “a.0 = 4”, 
> no “a[0] = 4”) Note that if we gain an equivalent to C++’s constexpr, then 
> static indexing mode could be spelled with the subscript operation.
> * For each array instance not initialized on declaration, define a secret 
> extra Boolean-array object that keeps the initialization state of each 
> element of the first array. Of course, this means tracking each element read 
> and raising a run-time error if not initialized first.
> * Something I haven’t considered.
> 
> If anyone from the original Swift team is around: is this why you didn’t add 
> fixed-size arrays at the start? (Or did you just forget?) I don’t think you 
> missed a way to link FSAs to DI; the two are just incompatible (if you want 
> to keep the way most people use arrays).
> 
> So I’m asking for either some way to make FSAs and DI work together that I 
> missed. Or start a discussion on how undefined behavior on uninitialized-data 
> reads should work on compiler, ABI, and run-time levels.

Right now, my solution is run-time deterministic initialization, but only to 
fixed-size arrays that are either local objects or stored instance properties. 
Other instances require the array to be initialized in one shot. To segregate 
code initializing an array, a special attribute suspends the full 
initialization requirement in function arguments.

Deterministic Initialization at Run-time

For each local object of a fixed-size array type that is not fully initialized 
at declaration and has at least one call to its subscript method and/or used as 
a fragmentary argument, there shall be a secret map object indicating which 
elements of the array have been initialized. When an element is initialized, 
either statically or dynamically, the corresponding flag in the initialization 
map shall be set. When an element is read statically or dynamically, the flag 
is checked before access, and a run-time error shall be triggered if the 
element has not been yet initialized. (The check can be elided if the element’s 
initialization and access were both static.) The same triggering occurs if the 
array as a whole is read and at least one element is uninitialized, unless the 
array’s access is being passed as a function argument with the corresponding 
parameter having the “fragmentary” attribute.

(An array that does not need run-time deterministic initialization checks still 
has the compile-t

Re: [swift-evolution] [Pitch] Array full proposal

[Daryle Walker via swift-evolution]

> On Jul 13, 2017, at 1:28 PM, Robert Widmann  wrote:
> 
>> On Jul 12, 2017, at 9:09 PM, Daryle Walker > > wrote:
>> 
>>> On Jul 12, 2017, at 4:05 PM, Robert Widmann >> > wrote:
>>> 
>>> I think this proposal is trying to do too much at once.  Correct me if I’m 
>>> wrong, but you’re proposing
>>> 
>>> 1) New sugar for fixed-length arrays without a corresponding stdlib 
>>> declaration
>> 
>> IIUC, “sugar” means an easier way to use existing functionality, right? In 
>> this proposal, there is neither sugar nor a standard library declaration for 
>> the same reason: these arrays are a new primitive at the user and ABI 
>> levels, not a library type. What is the (existing since you mentioned sugar) 
>> primitive you’re expecting a library fixed-size array to be based on?
> 
> “Sugar” means an equivalent way to spell something concrete, but here there 
> is nothing concrete.  We’d be hard-coding a magical library type into the 
> compiler which is something that, up to now, we have refrained from doing 
> because it massively complicates type checking and forces us to compromise to 
> work around “just this one corner case”.   Our notion of a “primitive” is not 
> the same as C and C++; Int, Float, String, these are all Standard Library 
> types - that happen to be backed by compiler intrinsics in some cases.

I don’t mean fixed-size arrays are a type vs. Int / Float / String (i.e. 
primitive types), but a kind of type vs. class / struct / enum / tuple (i.e. 
type primitives). It’s a primitive because it cannot be implemented by existing 
features. It's why the proposal mentions bit-code representations and ABI 
changes instead of library ones (besides support).

>> 
>> Obviously, this means arrays can’t be implemented until at least Swift 5.
>> 
>>> 2) Arity and type inference for literals
>> 
>> I don’t know what you mean by these.
> 
> 
> var b: [_, _] = [3.14159, 2.71828]
> 
> On the syntactic side: underbar has a very specific meaning in this language, 
> and “infer this type/arity” isn’t one of them.

I guessed this after I woke up this morning. A way around this would be a new 
(but similar) kind of literal. But we’ve already used up all the ASCII 
bracketing character pairs. And you see there’s problems reusing the square 
brackets that array- and dictionary-literals use. Maybe we can chord the square 
brackets with something else:

#[1, 2, 3, 4]#  // [4: Int]
#[6; 1, 2, 3, 4]#  // [6: Int], last two elements to be initialized later
#[6; “a", “b", “c", “d", default: “k"]#  // [6: String], all elements 
initialized, need semicolon since the comma and colon are already used
#[6; 0: “a", 2: “c", 1: “b", 3: “d", default: “k"]#  // [6: String], with 
specific indexes assigned per element initializer
#[2, 2; #[0, 0]#: 1, #[0, 1]#: 2, #[1, 0#]: 3, #[1, 1]#: 4]#  // [2, 2: Int], 
this form gets long really fast, maybe use the closure version
#[1, 2, 3, 4]# as [2, 2: Int]  // Reshaping uses less text
#[0;]#  // Empty array
#[]#  // Also empty array, can be used a shortcut initializer for any FSA to 
indicate no elements initially initialized

>> 
>>> 3) Default initialization semantics for arrays including a DI exception for 
>>> fixed-length arrays that aren’t fully initialized 
>> 
>> My first thought was full initialization, like other objects, but someone on 
>> the list really wanted a way to not have full initialization. I could see 
>> his point; filling in a bunch of zeros for a large array for math purposes 
>> could get expensive, especially if the values are immediately ran over. Even 
>> if we make closure-initialization return non-optionals, we still have to 
>> worry when an array is filled by a loop that gets exited early.
> 
> As long as you have this magical type, you should probably give it some 
> magical methods.  A “backfill” initializer, perhaps.  We cannot break DI just 
> because it’s syntactically inconvenient.
> 

There’s already the “default” term in extended array literals. And the “func” 
term allows the elements to be determined via closure.

For DI, it’s worse than you think, which is why I put out a separate post on 
this issue. DI assumes one sub-declaration per sub-object; the raison de-tere 
for arrays is to defeat this assumption. DI and FSAs are fundamentally 
incompatible; something has to break (forced initialization on declaration, 
static array indexing, run-time DI, or undefined behavior on possible 
uninitialized reads).

> You’ve also stumbled onto the notion of a “reasonable default”, which for a 
> language with a rich type system is a farce.  We can’t assume every type has 
> some reasonable default that we can fill in automatically because many types 
> don’t (for an extreme example, see Never).
> 
>> 
>>> 4) 2 new attribute declarations for unspecified concurrency semantics
>> 
>> Why not add some modern features relative to classic C? Or is it 

[swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

[Daryle Walker via swift-evolution]

As I understand it, Definitive Initialization means the Swift compiler will 
make sure an instance is fully initialized before the first attempt to read it. 
It does not require mandatory assignment at declaration; an instance can be 
declared with no initializer and receive an assignment at a later point.

* Class and structure types are considered OK by DI when an initializer is 
called.
* Enumerations can either use an initializer or have an enumeration-case 
assigned for DI.
* Compound types (function pointers and tuples) use assignment (possibly at 
declaration) for DI.
* Tuples can also have the individual members can be tracked for DI. A member 
has to be initialized by the time that member or the entire tuple is read 
(whichever comes first).

Tuples (and the other types) can statically determine when a sub-object is 
initialized. When adding a new member, via new text in the source code, a 
corresponding new line(s) of code has to be added during the initialization 
sequence. But built-in arrays, no matter how they’re defined, would be 
different. The whole point of arrays is to allow adjustment the number of 
sub-objects without per-sub-object alteration to the array type’s declaration 
code. That means you can’t write out all the member initializations in advance 
(in general). And that means you generally use a loop and subscripting instead. 
And since that moves the references to which elements get initialized to 
run-time, we have a fundamental incompatibility with definitive initialization. 
(The fixed-size array proposal I recently posted about does have a static 
indexing mode, but the point I’m making here is that it doesn’t scale from the 
perspective of the regular array interaction model.)

Besides banning fixed-size arrays forever and ever (which just hides the 
problem), we’re limited to:
* Mandatory assignment at declaration, and the initializing expression has to 
cover all elements
* If arrays keep a static indexing mode, apply DI to an array instance using 
that. This would mean changing the initialization sequence code every time the 
number of elements is adjusted. And the initialization would have to be from 
the static indexing mode for DI to recognize it (i.e. always “a.0 = 4”, no 
“a[0] = 4”) Note that if we gain an equivalent to C++’s constexpr, then static 
indexing mode could be spelled with the subscript operation.
* For each array instance not initialized on declaration, define a secret extra 
Boolean-array object that keeps the initialization state of each element of the 
first array. Of course, this means tracking each element read and raising a 
run-time error if not initialized first.
* Something I haven’t considered.

If anyone from the original Swift team is around: is this why you didn’t add 
fixed-size arrays at the start? (Or did you just forget?) I don’t think you 
missed a way to link FSAs to DI; the two are just incompatible (if you want to 
keep the way most people use arrays).

So I’m asking for either some way to make FSAs and DI work together that I 
missed. Or start a discussion on how undefined behavior on uninitialized-data 
reads should work on compiler, ABI, and run-time levels.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] Array full proposal

[Daryle Walker via swift-evolution]

> On Jul 13, 2017, at 7:09 AM, Gor Gyolchanyan  wrote:
> 
> Yes, by nominal tuples I did mean a struct definition somewhere in swift’s 
> standard library.
> 
> Seems like there are some quirks to tuples in Swift that I’m not aware of. I 
> always assumed that they are packed ordinary structures. Since structure 
> member offset is a compile-time constant, using tuples for arrays would not 
> really be bad for performance, unless I’m missing something.

I’ve been looking at the ABI documents. Structures and tuples can be packed 
ordinary product types, like in C. But the Swift people want to reserve the 
right to do extreme rearrangements, like packing bitwise-smaller members 
between the spacing of the larger ones. (This would mean later-declared 
sub-objects won’t necessarily have their addresses in increasing order.) 
Tragically, the current need for tuples to have an “array mode” would block 
this optimization. Having fixed-size arrays as a separate primitive would allow 
tuples to have tuple-specific optimizations and arrays to have array-specific 
optimizations without relying on implementation conventions.

> The C++ style compile-time wizardry is a subpar solution because it’s a hacky 
> workaround due to lack of proper compile-time tools. If Swift would some day 
> gain ability to execute imperative metaprogramming code that would manipulate 
> the types at compile-time, all problems of this sort would be solved forever. 
> But depending on how Swift compiler is implemented that may or may not be a 
> monumental endeavor.

Since arrays (I think) pre-date functional programming, generics, 
meta-programming, and other “modern” language features, requiring those 
features as prerequisites for arrays seems weird.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] Array full proposal

[Daryle Walker via swift-evolution]

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

> On Jul 12, 2017, at 4:30 PM, Gor Gyolchanyan  wrote:
> 
> I agree, given the current state of Swift, fixed-sized arrays are way too 
> magical.

Any more “magical” than the existing primitive types?

> I’d suggest postponing the idea of fixed-sized arrays (even though I myself 
> have ached for them for a long time now) until its prerequisites are met.
> 
> There are three language features that have been discusses before that are 
> required for this:
> Variadic generic parameters.
> Tuples as nominal types with a variadic generic parameter and a tuple 
> concatenation ability.
> Non-type generic parameters (probably, only compile-time value types).

Improved generics would synergize with fixed-size arrays, but are not a 
prerequisite.

Wouldn’t nominal tuples be structures? Not that it matters here since FSAs 
aren’t quirky tuples. (I mentioned in the proposal that no language that I know 
of does this; homogenous and heterogenous product types are always distinct 
kinds of types.)

> In these terms, a fixed-sized array would be a type that takes an Int as a 
> generic parameter and uses a variadic tuple for its storage. If C++ templates 
> has taught us anything is that metaprogramming can be used for achieving 
> fantastic compile-time wizardry, like converting a single integer generic 
> parameter and a single generic type parameter  to a generic homogeneous 
> variadic type parameter (by using a recursively defined variadic parameter 
> dummy type).

I thought Swift was to avoid that kind of wizardry. And unless you don’t want 
any of the optimizations array operations get, then the compiler has to analyze 
tuple types to trigger “array mode."___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Array full proposal

[Daryle Walker via swift-evolution]

> On Jul 12, 2017, at 4:05 PM, Robert Widmann  wrote:
> 
> I think this proposal is trying to do too much at once.  Correct me if I’m 
> wrong, but you’re proposing
> 
> 1) New sugar for fixed-length arrays without a corresponding stdlib 
> declaration

IIUC, “sugar” means an easier way to use existing functionality, right? In this 
proposal, there is neither sugar nor a standard library declaration for the 
same reason: these arrays are a new primitive at the user and ABI levels, not a 
library type. What is the (existing since you mentioned sugar) primitive you’re 
expecting a library fixed-size array to be based on?

Obviously, this means arrays can’t be implemented until at least Swift 5.

> 2) Arity and type inference for literals

I don’t know what you mean by these.

> 3) Default initialization semantics for arrays including a DI exception for 
> fixed-length arrays that aren’t fully initialized 

My first thought was full initialization, like other objects, but someone on 
the list really wanted a way to not have full initialization. I could see his 
point; filling in a bunch of zeros for a large array for math purposes could 
get expensive, especially if the values are immediately ran over. Even if we 
make closure-initialization return non-optionals, we still have to worry when 
an array is filled by a loop that gets exited early.

> 4) 2 new attribute declarations for unspecified concurrency semantics

Why not add some modern features relative to classic C? Or is it possible for 
these to be automatically determined (and carried out) by the compiler? I don’t 
think the vector-unit one can.

> 5) A magical compiler intrinsic that declares loop counters

Having the compiler figure out the best way to iterate an array seems a lot 
better than manually doing a bunch of loop and range calls, especially for 
multi-dimensional arrays. (I want one loop statement, no matter the number of 
dimensions.) But without those manual calls, you need some other way to 
determine your position in the loop.

> 6) Static collection subtyping constraints referencing convertibility 
> constraints we don’t currently have

I copied that from the section of the ABI document about tuples. We could drop 
it.

> 7) Tuple conversions

Since these arrays will replace manually homogenous tuples as the conversion 
for C arrays, we need a way to handle older code. I probably wouldn’t have 
bothered except for backwards compatibility.

Are manually homogenous tuples, with the multiplicity of the element type is 
specified with lexical repetition instead of a number, the sugar from point 1? 
If so, that use would be depreciated, not continued.

> I believe your aims are noble, and this is certainly a tremendously important 
> problem we need to solve, but I think there needs to be a measured response 
> to the current state of things.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch] Strong typedef, version 0.2

[Daryle Walker via swift-evolution]

I’ve updated my strong type-alias proposal at 
. There’s 3 
revisions instead of 2 because I missed a big error.

* I removed all the state-restriction stuff (but still noted as a possible 
future direction). Besides removing a lot of text, it also means that a strong 
alias of an enumeration must publish all the cases.
* Rearranged some text, screwing up the diff some more.
* Added the concept of an implementation initializer, as the default way to 
convert from the original type to the alternative.
* Casts between alternative types and/or their original type all use 
unconditional-as.
* Added “AlternativeStats” generic type to contain type-aliases to the original 
type and conversion functions without having to name that original type.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch] Array full proposal

[Daryle Walker via swift-evolution]

Spent the past week coming up with a full proposal for fixed-size arrays. I 
wrote it mainly from the bottom upwards. There may be some inconsistencies. And 
I'm not entirely sure what "structural sub-typing" means, or if it's 
appropriate for arrays.



Sent from my iPad___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Get all the protocols a type supports

[Daryle Walker via swift-evolution]

I mentioned this in another thread recently. Here’s a more formal pitch.

Query a Type on Its Protocols
Proposal: SE- 
Authors: Daryle Walker , Author 2 

Review Manager: TBD
Status: Awaiting review
Introduction
This proposal adds a type-alias operator for all the protocols a given type 
supports.

Swift-evolution thread: Discussion thread topic for that proposal 

Motivation
Manipulations of protocols with types are explicitly user-driven. A protocol 
has to be associated with a type by a user at the type's primary definition 
block or in an extension's definition block. Protocols have to be combined by 
the user with composition or inheritance. There is currently no way to create 
or use protocols without the user knowing all the protocols involved in advance.

There is (at least) one case where the user can't know all the protocols in 
advance. It's when wanting to know what protocols a given type already has. 
Currently, that's not very useful; an implicit list of all the protocols of a 
type only helps when making a item conform to the protocols of another type. A 
user can't just manually walk all the protocols in the type's definition, 
because others may be added through extensions. Those other protocol 
introductions are walkable too, but they would have to be manually maintained 
(looking through all the source code, not just the type's primary file) after 
every source-code change.

Proposed solution
Although the list of protocols for a given type is (practically) open from the 
user's perspective, it's closed from the compiler/linker's perspective. 
Therefore, the list can be mechanically generated and updated.

The list will be represented as a type-alias. The alias is expressed by a new 
special operator that takes the source type as its only input. The alias acts 
like any other type-alias to a protocol; it can be used as a conformance source 
and can have .Protocol tacked on at the end for metatype analysis.

func integerTesting(_ sample: #protocols(Int32)) -> Int {
// Use "sample," which we know follows all of the same protocols as "Int32".
// Examples are "Int" and "Int64".
// (Note we can't go the other way because "Int32" doesn't support 
"MirrorPath"!)
}
The type accounting tables the compiler (and maybe linker) have to build during 
translation will get all the protocols a particular type conforms to. Then the 
compiler can add a new entry, the same as protocol compositions, and list all 
the discovered protocols in the entry's sub-protocol list. Since there is a new 
order dependency added (before using #protocols(MyType), the compiler has to 
analyze MyType and all possible affecting extensions throughout the program, 
then create a new protocol composition to insert), recursion loops may be 
possible [not sure how myself]. Loops, or nested computing of all-protocol 
lists that are too deep, should raise a compile-time error (too many resources 
used).

Using the #protocols operator on a type that doesn't conform to any protocols 
will return Any. Using the operator on a protocol returns that same protocol.

Detailed design
Add to "Grammar of a Type":

type → #protocols ( type )
Source compatibility
The changes should be strictly additive, including one new keyword.

Effect on ABI stability
The ABI should not be affected. The new type expression acts like a protocol 
composition, and the protocols making up that composition are determined at 
compile [and/or link?] time.

Effect on API resilience
This feature most likely won't be used in standard library code, so the API 
won't be affected. Anything that uses an all-protocol list on a library type 
will get affected during library revisions.

Alternatives considered
The alternative is to not add this operator. Then users still research what 
protocols a target type uses, manually add said protocols at the appropriate 
place, and hope that some extension declaration wasn't missed.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch] strong typedef

[Daryle Walker via swift-evolution]

I uploaded my proposal for strong type-aliases at 
>. My brain 
is somewhat fried from working for several days writing and rewriting this, so 
new sets of eyes finding issues is appreciated.

* I originally had “retype” as the name, but it’s strictly a verb while 
“struct(ure),” “enum(eration),” and “class” are nouns, hence “alter(native).” 
Maybe there's an even better name out there? The header looks a little funny 
because the type being altered is after the colon, and not the identifier 
immediately next to “alter”.
* A lot of the text is a consequence of the restriction/validation dynamic, 
should that be dropped? Dropped for now? Note that dropping it will require sum 
alternative types to include all of the cases from their implementation type.
* If a bunch of members are introduced from the implementation type as a set of 
function overloads or a protocol set, should there be a way for a 
directly-defined member to shadow over a published member instead of 
co-existing as overloads? For instance:

alter MyInt16: Int16, Hashable {
publish Equatable
var hashValue: Int {
return 2000 &+ super.hashValue
}
}

If I change the published protocol to Hashable, I’d get an illegal overload 
error. Should it be changed to let a directly-defined member override a 
published one? If so, should a plain declaration work, or should “override” be 
added to the directly defined version (so an unintentional shadowing is flagged 
as an error)?

* If we keep restrictions, what about protocols that return or otherwise output 
Self? They could return values that are valid for the implementation type but 
not the current alternative type. How can I fix this 
co-variance/contra-variance mismatch? Or is this an argument to drop restricted 
alternative types?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

[Daryle Walker via swift-evolution]

> On Jul 2, 2017, at 10:15 PM, Christopher Kornher  wrote:
> 
> A full-fledged introspection system should provide this information, which I 
> suppose could be useful for creating proxies through code generation or 
> dynamic Objective-C like features, should they ever be added to the language. 
> Would that be sufficient for your needs? It is not clear to me what problem 
> you are trying to solve.
> 
> Hopefully I won't stir up too much trouble by saying that this kind of 
> capability is very useful in Objective-C for mocking, for example.

I have the proposal for my use case out now at 
>.

Look at:

alter MyInt16: Int16, Hashable {
publish Equatable
var hashValue: Int {
return 2000 &+ super.hashValue
}
}

If I wanted to copy Int16 completely, I couldn’t write the full protocol list 
because it’s open-ended from the user’s perspective due to extensions. However, 
the list is closed from the compiler/linker’s perspective, so we can synthesize 
an all-protocol list:

alter MyInt16: Int16, #protocols(Int16), ANewProtocol {
publish #protocols(Int16)
// Define new members here, some of which implement ANewProtocol
}

Besides this, maybe we could do some analysis using 
#protocols(MyType).Protocol. (Oh, completely copying Int16 is still useful 
because functions with them are considered separate overloads, unlike a 
type-alias.)

I’m not sure what you mean by a full-fledged introspection system, but my 
current use for it requires a solution that is 100% workable at compile-time.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

[Daryle Walker via swift-evolution]

> On Jul 1, 2017, at 2:07 AM, Brent Royal-Gordon <br...@architechies.com> wrote:
> 
>> On Jun 30, 2017, at 6:17 PM, Daryle Walker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Given a type MyType, how can I get a type-alias to the type’s protocols? If 
>> MyType conforms to Protocol1 and Protocol2, I would want something like
>> 
>>  typealias MyProtocol = Protocol1 & Protocol2
>> 
>> (and Any if MyType doesn’t conform to any protocols). Does this facility 
>> already exist in Swift? I don’t think it does, so I proposed the hybrid 
>> “MyType.Protocol” syntax to express the idea.
> 
> Leave the syntax aside. What are you planning to do with this feature? I 
> understand that you want to have some way of saying "composition of all 
> protocols this type conforms to"; I don't understand *why* you want it or 
> what kind of code you would need it for.


It wasn’t until I started this thread that I realized that Swift didn’t have a 
way to get a bulk list of a type’s protocols. A little later, I came up with a 
reason why this never came up before (or at least not often): knowing this 
isn’t really useful.

You could use this to make MyTypeB conform to all protocols of MyTypeA. But 
then you’re stuck. The list of protocols for a type is a closed from the 
linker’s perspective, but open from the user’s perspective. The user couldn’t 
write all the methods needed unless the unknown ones all have default 
implementations. The proposal I’m coming up with has a facility to copy all the 
members of one type to another. You can specify by exact member name, or you 
can specify a protocol to get copies of all applicable members at once. This is 
where an all-protocols alias can help. With manual copying, the user’s 
cardinality of members copied is usually less than what’s available, with an 
automatic list the cardinalities are always equal.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] How many kinds of declarations can a named type hold?

[Daryle Walker via swift-evolution]

I think I got most of this, but it’s hard to completely figure out because the 
information is scattered across the grammar.

So, I’m coming up with a statement to copy over a member from one type to 
another:

publish MEMBER-FROM-OTHER-TYPE

and I’m trying to encapsulate this into a grammar. This requires me to figure 
out how to name every single declaration in a type. I got so far:

published-member → decimal-digits
published-member → type-identifier
published-member → identifier | identifier ( argument-names_opt )
published-member → operator | operator (argument-names_opt )
published-member → init | init (argument-names_opt )
published-member → init ? | init ? (argument-names_opt )
published-member → init ! | init ! (argument-names_opt )
published-member → subscript | subscript ( argument-names_opt )

The first line is for tuples, and the rest are for struct/enum/class. The 
second line covers some generics, but I don’t mention generics anywhere else. 
The third line covers properties and functions, while all the following lines 
over functions. There are two branches for those lines to cover all overloads 
sharing a name and to cover a specific overload.

Do I have to mention generic stuff in any of the lines past the second? Are 
there declaration kinds I’m straight-up missing? (Remember that identifier 
covers constants; variables; type-aliases; enumeration cases; inner structure, 
enumeration, class, and extensions; and operator precedence groups.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

[Daryle Walker via swift-evolution]

> On Jun 30, 2017, at 9:26 PM, Robert Bennett  wrote:
> 
> I’m not at a computer to test this, but would this work:
> 
> typealias T = P1 & P2
> extension C: T {}
> 
> Now T is C.Protocol

Is C supposed to be a type or a protocol? I’m guessing a protocol since I don’t 
think “C.Protocol” is currently legal for a type. In either case, T wouldn’t 
include protocols introduced to C in some other way.

Regardless of the answers for your example, I don’t want to “write” new 
protocols to C, but “read” the protocols C already has.

The “MyType.Protocol” was a suggestion that I wondered if it would complicate 
parsing. Alternate syntax opinions requested.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

[Daryle Walker via swift-evolution]

> On Jun 30, 2017, at 8:49 PM, Adrian Zubarev  
> wrote:
> 
> What are you proposing here, I don’t get it?! What role should .Protocol 
> play? .Protocol is an ugly hack in Swift which should be removed anyway. It 
> does more harm than good.
> 
I’m not proposing anything right now. I’m asking a question; the proposal that 
needs the answer can be put off for later.

Given a type MyType, how can I get a type-alias to the type’s protocols? If 
MyType conforms to Protocol1 and Protocol2, I would want something like

typealias MyProtocol = Protocol1 & Protocol2

(and Any if MyType doesn’t conform to any protocols). Does this facility 
already exist in Swift? I don’t think it does, so I proposed the hybrid 
“MyType.Protocol” syntax to express the idea.

If you don’t like the current “.Protocol” syntax, then I guess you don’t like 
it for this idea. I’m also requesting suggestions for alternate syntax.

#protocols(MyType)

is an example.

I guess this should be a separate proposal from my other one.
> Our revised proposal was deferred from Swift 4:
> 
> https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md
>  
> 
— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] Would having "MyType.Protocol" to indicate a type's protocols mess anything up?

[Daryle Walker via swift-evolution]

We have

MyType.Type

to indicate the meta-type of a type. And

MyProtocol.Protocol

to indicate the meta-type of a protocol. Would it be OK to add

MyType.Protocol

to identify all the protocols MyType follows? The result would be like if each 
protocol was connected by “&”, or “Any” if the type doesn’t follow any 
protocols.

…

Woah, I realized that this could be a bigger than anticipated. A type can 
specify its protocols directly, or through extension(s). Heck, I do that in my 
Cocoa projects to segregate each aspect of a class. So I guess we have to allow 
the protocol list to include those imported via extensions.

…

Why do I want to do this? It’s part of my 
retype/strong-typedef/alternate-interface idea. I originally made the developer 
list each protocol to re-implment separately in the export list and the 
protocol list. But that would be tedious for a long list of protocols. So I’m 
thinking “why not have a way to specify all of the protocols at once.” But I’m 
not sure on the syntax, that’s why I’m asking here. Alternatives could be 
things like “#protocolof(MyType)”. Unless we already have this capability?…

(Having a retype that repeats all of the implementation type’s protocols is 
still useful. The types would have the same interface, but still don’t share 
function overloads.)

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] Object aliases

[Daryle Walker via swift-evolution]

> On Jun 30, 2017, at 1:11 AM, John McCall <rjmcc...@apple.com> wrote:
> 
>> 
>> On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Swift is currently an alias-adverse language. The model for the equivalent 
>> of pointers is supposed to be for short-term use, and not persisted. Other 
>> constructs that would use references: read-write properties, read-write 
>> subscripts, and inout function parameters, can all be implemented by 
>> copy-in-then-copy-out, presumably to avoid alias dynamics and its 
>> anti-optimizations. So the scope of aliases here will be limited to 
>> local-scale renaming of object locations that the compiler can connect 
>> statically.
>> Yes, the use case is currently weak, but it is a stepping stone for stronger 
>> cases, like changing the interface of an object with (currently not in the 
>> language) strong type-aliases without copies.
>> 
> 
> We usually expect language features to stand on their own.  Certainly 
> something as core as a new kind of declaration would be expected to.
> 
> Anyway, this feature is rather similar to what I called a "local ephemeral 
> binding" in the ownership proposal, except that your alias does not access 
> the referenced storage until it itself is accessed.  Unfortunately, this 
> actually makes it *more* complex, rather than less, as it creates a new way 
> to abstract over storage, including local storage.

I was thinking posing aliases would be like symbolic substitution; we could 
replace the alias with the text defining its source expression everywhere and 
there should be no efficiency change. But I would want any evaluation of the 
(sub-)object’s location to be computed once; is that where complexity could 
come in? I was hoping that object location determination could be done at 
compile-time; that’s the reason for restricting what kinds of objects can be a 
source object.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] Object aliases

[Daryle Walker via swift-evolution]

> On Jun 29, 2017, at 6:45 PM, Beta  wrote:
> 
> So, what’s the difference between this and teaching Key Paths to look through 
> tuple indices - that was the only part of your example I couldn’t directly 
> express.

You’re talking about Apple’s Cocoa’s KVC/KVO, right? The key-path method is 
like the lenses idea bouncing around this thread, except KVO/KVC doesn’t take 
Swift-specific stuff (like tuples) into account. Key-path and lenses are 
resolved at run-time, while the posing-aliases here should be resolved at 
compile-time (or whenever the memory locations of globals and named locals are 
resolved).

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] Invariant checks on strong typedefs?

[Daryle Walker via swift-evolution]

In my retype idea, you can bring back symbols from the implementation type with 
an "export" command. There's an "export default" command to bring back all the 
numbered fields of a tuple or all the cases of an enum. But what would it mean 
to NOT include all enum cases?

One option is to ban this; a retype of an enumeration gets all cases 
automatically, no need to be explicit nor any way to exclude. But I think 
leaving it in is cooler; we can make a retype be a restricted type relative to 
its implementation type. Now there would be a new problem. What happens when we 
have a retyped object pose as its original type, but assign it a case value 
banned in the retype?  How would we let the object check its invariant, if at 
all (i.e. leave it quasi-undefined behavior)? How would we implement any 
rejection, a throw?

I was thinking of a special method. And it would apply to any retype; not just 
enumerations, but tuples and structs too. 

Sent from my iPhone
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Object aliases

[Daryle Walker via swift-evolution]

I put this proposal, with an addendum about lenses, at 
.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] Trying to grok the ABI documents, w.r.t. strong typedefs

[Daryle Walker via swift-evolution]

I’m trying to understand two of the ABI documents, 
 and 
, 
with respect to a strong type-alias idea I just posted:

retype IDENTIFIER: IMPLEMENTATION-TYPE (“,” PROTOCOL)* {
// New methods and computed properties
// Maybe type-level stored properties
// Optionally export symbols from the original type to this one
}

I think we would need a new ABI entry for re-types. I think the implementation 
type would have to be a value type (structs, enums, tuples, and possibly 
someday fixed-sized arrays); I couldn’t get how to make a retype work with a 
class’s witness information block (which are customized to fit Objective-C 
compatibility) and what would it mean to shadow something that is a pointer to 
the real information anyway. This also means that retypes are always value 
types themselves.

Looking at the ABI Stability Manifesto:

* A retype has the same data layout as its implementation type. It has the same 
trivial and bitwise-movable status as its implementation type.
* The value metadata for a retype needs a pointer to its implementation type’s 
value metadata. I don’t know if a retype should share its witness table with 
the implementation type, or have a separate table that has a pointer to the 
original’s table.

Looking at the ABI doc:

* A retype has the same layout as its implementation type.
* The common metadata layout of the type metadata has a new kind value for 
retypes.
* In addition to the common metadata layout, a retype’s metadata has a nominal 
type descriptor, a reference to the parent metadata record, a reference to the 
implementation type’s metadata record, then possibly a generic parameter vector.
* The nominal type descriptor needs a new kind for retypes. I’m not sure if it 
needs any field/case/payload data.
* I don’t know if new mangling operators are needed for retypes, or if they can 
reuse their implementation type’s codes.

Other:

* I guess methods and computed property getters & setters of a type are listed 
with the general functions, with some marker of where the “self” pointer is. 
New methods of a retype would need new function entries, but I don’t know if 
exported methods would just reuse the implementation type’s method entry, or 
would new functions be created that just forward to the implementation type’s 
versions.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] Object aliases

[Daryle Walker via swift-evolution]

> On Jun 23, 2017, at 9:29 AM, Nevin Brackett-Rozinsky 
>  wrote:
> 
> This sounds similar to lenses. Have you looked at previous lens discussions 
> on-list?

I had no idea what a lens is. Nor was is easy to figure out since I can’t read 
Scala, JavaScript, or Haskell. From what I can grok from those papers, I’m 
guessing it’s like C++’s pointer-to-member, but it’s more like a group of them 
forming an access chain from a source object to a (possibly nested) sub-object. 
It seems like a functional programming thing.

>From a high-level view, a poser is a kind of a lens. But the low-level details 
>are completely different.

* A lens is a first-class type, probably part of a Standard Library. Posers are 
symbolic substitution; they’re deliberately not first-class types.
* As a first-class type, lenses have data, indicating the path from source to 
sub-object. There is no data for a poser, since the concept is realized during 
translation.
* A lens, a far as I understand, targets a sub-object. A poser can target the 
entirety of a named object.
* A poser can cover substituting an object of one type for a layout-compatible 
type (including future strong type-aliases). Lenses don’t cover this use case.
* A poser’s purpose is to defeat copy-in/out semantics with reference 
semantics. How lenses work on copy-in/out vs. reference is unspecified.

Swift tries to avoid direct reference semantics, and does two-way object 
passing as (or as-if) copy-in & copy-out. This avoids having to do the 
pessimizations needed for safety when one object reference may alias another. 
Posers are limited to minimize these anti-optimizations. Posers can only be 
implementation aids for functions; they cannot be globals nor a 
property/associated-value (not the case for lenses since they’re first-class 
types). Posers can only alias a (sub-)block of statically determined memory 
(not the case for lenses either). Posers are not passed a function arguments or 
returns; the original object is instead.

Something I like about the poser syntax is that we could extend it to actual 
lenses someday (when we can make pointer-to-member expressions).

Oh, some previous discussions are:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006663.html
 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019138.html
 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005236.html
 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012541.html
 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022479.html
 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004555.html
 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160801/025882.html
 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006262.html
 

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161212/029531.html
 


The “Lenses in Swift” video is actually at 
>.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Revisiting SE-0110

[Daryle Walker via swift-evolution]

> On Jun 24, 2017, at 12:25 PM, Djura Retired Hunter 
>  wrote:
> 
> I didn't understand your example at all. Care to elaborate?
> 
> Elviro
> 
>> Il giorno 24 giu 2017, alle ore 18:05, Daryle Walker > > ha scritto:
>> 
>> 
>>> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution 
>>> > wrote:
>>> 
>>> It's probably late to just casually add a couple of cents to a discussion 
>>> that has been going for so long, but it seems to me that from a user 
>>> standpoint, that uses types to structure their programs and define logic 
>>> and relationships, isomorphic types should be considered the same by the 
>>> compiler. The added burden of distinguishing between, to say, a function 
>>> that takes 2 arguments and one that takes a single tuple of two arguments 
>>> doesn't seem useful at all, at least from the standpoint of the types 
>>> involves. All the rest, like named parameters or tuple labels, are just 
>>> really about style and convenience, but isomorphic types, while not 
>>> strictly equal (the very concept of "equal" is in fact a huge deal in 
>>> abstract mathematics) are for all means "equivalent" for the world-modeler.
>> 
>> Doesn’t seem useful?…
>> 
>> let myFunc: (MyTypeAlias) -> Int = /* … */
>> 
>> Does the function pointer have a single parameter? Or does it trigger 
>> Super-Secret Tuple-Destructing mode and actually indicate two parameters? My 
>> secret unknown single type should always be a single type, no matter what 
>> kind of type it is.

(A, B, C)  ((A, B), C)  (A, (B, C))

You’re saying partitions aren’t important. I’m saying that they are. Even 
though the second two tuples above are implemented like the first, I wouldn’t 
want them to be indistinguishable from an user’s standpoint. I wouldn’t want my 
two-argument functions magically become a three-argument one due to 
implementation details.

My previous example will stay an one-argument function for any non-tuple type 
behind the alias. But if it’s a tuple type, my assumption breaks because your 
rules would ban tuples from being first-class types.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Revisiting SE-0110

[Daryle Walker via swift-evolution]

> On Jun 23, 2017, at 7:46 AM, Elviro Rocca via swift-evolution 
>  wrote:
> 
> It's probably late to just casually add a couple of cents to a discussion 
> that has been going for so long, but it seems to me that from a user 
> standpoint, that uses types to structure their programs and define logic and 
> relationships, isomorphic types should be considered the same by the 
> compiler. The added burden of distinguishing between, to say, a function that 
> takes 2 arguments and one that takes a single tuple of two arguments doesn't 
> seem useful at all, at least from the standpoint of the types involves. All 
> the rest, like named parameters or tuple labels, are just really about style 
> and convenience, but isomorphic types, while not strictly equal (the very 
> concept of "equal" is in fact a huge deal in abstract mathematics) are for 
> all means "equivalent" for the world-modeler.

Doesn’t seem useful?…

let myFunc: (MyTypeAlias) -> Int = /* … */

Does the function pointer have a single parameter? Or does it trigger 
Super-Secret Tuple-Destructing mode and actually indicate two parameters? My 
secret unknown single type should always be a single type, no matter what kind 
of type it is.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch] Object aliases

[Daryle Walker via swift-evolution]

I started a thread earlier this week about strong type-aliases and object 
aliases. Here’s a fuller proposal on object aliases.

Feature name
Proposal: SE- 
Authors: Daryle Walker , Author 2 

Review Manager: TBD
Status: Awaiting review
During the review process, add the following fields as needed:

Decision Notes: Rationale , 
Additional Commentary 
Bugs: SR- , SR- 

Previous Revision: 1 

Previous Proposal: SE- 
Introduction
This is a proposal to define aliases to objects.

Swift-evolution thread: 1 

Motivation
Aliasing allows a named object to actually refer to another object instead of 
newly-allocated storage. Referring to an object with a simple name isn't very 
useful, but referring to an object needing a complex expression to point to it 
can help with reducing typing.

However, aliasing has a cost. Compilers have to make certain assumptions if 
objects can have multiple names referring to them, and these assumptions reduce 
what kinds of optimizations can be made.

Language design can make a difference in how code can be optimized. Languages 
like C and C++ assume aliasing is allowed by default, limiting how many 
optimizations can be done. More recent versions of C have a keyword 
("restrict") to ban certain objects from aliasing. Other languages go the other 
way; you need to take extra measures to alias objects, since object handling 
bars aliasing by default.

Swift is currently an alias-adverse language. The model for the equivalent of 
pointers is supposed to be for short-term use, and not persisted. Other 
constructs that would use references: read-write properties, read-write 
subscripts, and inout function parameters, can all be implemented by 
copy-in-then-copy-out, presumably to avoid alias dynamics and its 
anti-optimizations. So the scope of aliases here will be limited to local-scale 
renaming of object locations that the compiler can connect statically.

Yes, the use case is currently weak, but it is a stepping stone for stronger 
cases, like changing the interface of an object with (currently not in the 
language) strong type-aliases without copies.

Proposed solution
The solution is to introduce a new kind of object declaration. It uses a new 
keyword pose in the same place as let or var. It must be initialized with an 
expression that specifies an object, and be typed with a layout-compatible type 
(like the unsafeBitCast function).

struct Sample {
var test1 = (1, 2, 3, "apple")
//...
func trial1() {
pose firstTestNumber = test1.0
print(firstTestNumber)  // prints "1"
//...
firstTestNumber = 4
print(test1.0)  // prints "4"
}
}
When an object is used, the compiler associates the object with some sort of 
location ID. An alias just reuses its original's ID instead of having one of 
its own.

Here, the substitution is simple, but longer chains are imaginable. With a 
local-scope limitation, aliases work kind-of like macro constants in C.

Detailed design
Add to the "Grammar of a Declaration":

declaration → alias-declaration
Add a new section "Grammar of an Alias Declaration":

alias-declaration → attributes_opt declaration-modifiers_optpose 
pattern-initializer-list
An alias declaration can only be in the local scope of a function. Expressions 
that describe source objects must be:

a named object, including function parameters
a member of a qualifying tuple object
a stored property of a qualifying struct (or class?) object
A source object must have a lifetime at least as long as any aliases to it. A 
source object cannot have willSet and/or didSetobservers. The alias poses as an 
object of its type annotation, defaulting to the source object's type if 
omitted. An annotation must be of the source object's type or a 
layout-compatible type. An alias has the same mutability status as its source 
object.

An alias has the same operations as its annotated type, using the storage of 
the source object. An alias used as an inout function argument is banned if it 
and at least one other inout argument share memory (in whole or in part).

Since source objects are restricted to have their storage established 
statically, the compiler can reuse a source object's location ID when an alias 
to that source is referenced. Since an alias doesn't escape its containing 
function (any returns or inout action would copy to/from the source object), 
additional global aliasing checks are avoided.

Source compatibility
Besides the new keyword pose, which should be conditional if possible, the 
changes are additive. I 

Re: [swift-evolution] [early Pitch] retype (or newtype): strong type-alias (typedef) for redoing an interface; also: object aliases

[Daryle Walker via swift-evolution]

I didn’t add a SuperReallyPeachyKeenProtocol example. It assumes we eventually 
add variadic generics:

retype TupleCollection: (T, …U), RandomAccessCollection allwhere U == T {
export default  // Without this, instances of “self” below would be “super” 
instead.

var head: T {
get { return self.0 }
set { self.0 = newValue }
}
var tail: (…U) {
// Put some cool template meta-programming here, thanks.
}

subscript(index: Int) -> T {
get { return index == 0 ? self.0 : tail[index - 1] }
set {
if index == 0 {
self.0 = newValue
} else {
tail[index - 1] = newValue
}
}
}
//…
}

// Put terminal specialization of TupleCollection<> here.

//…

func myFunc2() {
var myTuple: (Int, Int, Int, Int) = (0, 0, 0, 0)
pose myCollection = myTuple as TupleCollection

for i in myCollection {
i += 2
}
print(myTuple)  // (2, 2, 2, 2)
}

Now you don’t have to permanently add subscripting to tuple types.

[Oh, instead of expanding a parameter pack with U…, I automatically expand it 
with “where” variants where-any and where-all. The first considers each member 
of the pack separately and then applies logical-OR to the result (default to 
FALSE when empty). The second does a logical-AND (defaulting to TRUE when 
empty). The where-any marker could be renamed to “anywhere,” but that would 
need an “allwhere” to be consistent. Turns, out “allwhere” is a word, albeit 
archaic!]

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [early Pitch] retype (or newtype): strong type-alias (typedef) for redoing an interface; also: object aliases

[Daryle Walker via swift-evolution]

In one of my earlier fixed-size array proposals, I had two kinds of array 
types: a compound type and a nominal type. I dropped the latter because there 
wasn’t too much of a value-add, especially once I copied its unique features to 
the compound type. It would be like a compound array property wrapped by a 
struct, except that member wouldn’t have a proper name so you would have to use 
“super” to refer to the inner object.

I have been looking up on how Rust handles its array/vector types, and I saw an 
issue on adding complex numbers. I then recalled that “long” ago I read up on 
C++’s complex numbers and how that class isn’t supposed to have any padding so 
you can alias a large array of double into a large-ish array of complex. That 
could have been resolved another way if we had a strong “typedef” so a new type 
would have the EXACT layout as another type without wrapping it in a struct and 
risking padding.

Over the past few weeks, I seen requests here for a strong type-alias. And 
requests for “I know that tuples are supposed to be protocol-less, but I want 
to (automatically) slap SuperReallyPeachyKeenProtocol on them anyway”. Now I 
think I can put all of these together.

Name a New Type Based on an Existing One:

“retype” IDENTIFIER “:” ORIGINAL-TYPE (“,” PROTOCOL )* “{“
// Whatever, including exports…
“}”

If there is nothing in the braces, then the new type doesn’t any operations 
(besides the default assignment and “&” for function in-out parameters). You 
can get a reference to the object as the original type as “myNewObject.super”; 
it will have the same let/var status as the outer object’s declaration. Access 
to “super” lets you implement whatever new interface you want. Of course, you 
can implement new protocols added to the type list. The new type is implemented 
as the original one; no wrapping structs added; the same size, stride, and 
alignment.

You can republish parts of the old type’s interface. You use an “export 
OLD-NAME” declaration. There is also an “export default” declaration, which 
does:

* The application operator (i.e. “(whatever)”) for a function type
* The “.0”, “.1”, etc. member access for a tuple type
* All the original cases for an enumeration type
* Nothing for any other type

The default-export is optional for tuple and enumeration types, since you can 
export individual members or cases. Since there is no way to express the 
application operator in Swift, a function type’s retype has to use the 
default-export if it wants to export anything. All of the original type’s 
implementation of one of its direct or indirect protocols can be exported with 
“export TheOldProtocol”; but the new type won’t officially support the protocol 
unless it’s (directly or indirectly) in the new type's protocol list.

How do you initialize objects of this type? Besides using another object of the 
same type, you can use an object of the original type or of a retype that 
shares the implementation type as an initializer. If the initialization happens 
after the object’s declaration, then “expressionOfOtherType as MyReType” syntax 
has to be used. (Post-declaration initialization can use “myObject.super” 
instead.)

Now, I can do something like (assuming fixed-size arrays are added):

retype Complex: [2: T], Equatable /*, etc.*/ {
var re: T {
get { return super[0] }
set { super[0] = newValue }
}
var im: T {
get { return super[1] }
set { super[1] = newValue }
}

init(_: UninitializedFlag) {  // “UninitializedFlag” is a library enum type 
with case “.uninitialized"
super = []  // Leave uninitialized
}
init(real: T = 0, imaginary: T = 0) {
super = [real, imaginary]
}
//…
}

func someFunc() {
let scalars: [_: Double] = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
let rawComplexes = scalars as [5: [2: Double]]  // Reshape command
let firstComplex = rawComplexes[0] as Complex  // May have to use 
“Complex” if the “as” is too indirect.
//...
}

Object Aliasing

But what if I want to work on those scalars directly? What if I want to mutate 
my complex number objects and update the scalars too? What if we add a “pose” 
declaration, at the same level as “let” and “var”?

var scalars: [_: Double] = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
pose rawComplexes: [5: [2: Double]] = scalars  // OK as they have the same 
stride and inner non-array type
pose complexes: [5: Complex] = rawComplexes

complexes[0].re = -11
assert(scalars[0] == -11)

The source of a pose has to have an equal or greater scope (and lifetime) than 
the alias. (Instance- and type-level properties of a type definition are 
considered separately. An instance-level property can pose over a type-level 
one. A function-scope object can pose over a function argument, as long as it 
doesn’t try to persist after function-end.) A pose has the same let/var status 
as its source. (The source may not be directly marked as “let” or “var,” it may 
be a “pose” itself.) A pose always has to be initialized at declaration time 
with its source.

[Note: the 

Re: [swift-evolution] [Pitch] #error

[Daryle Walker via swift-evolution]

> On Jun 12, 2017, at 3:57 PM, Daryle Walker via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
>> On Jun 12, 2017, at 8:03 AM, Ben Rimmington <m...@benrimmington.com 
>> <mailto:m...@benrimmington.com>> wrote:
>> 
>> 
>>> On 11 Jun 2017, at 19:15, Beta wrote:
>>> 
>>> A proposal and implementation of #warning exist.  It has been judged out of 
>>> scope for Swift 3 and Swift 4 phase 2. 
>>> 
>>> https://github.com/apple/swift-evolution/pull/353 
>>> <https://github.com/apple/swift-evolution/pull/353>
>> 
>> See also "[Pitch] #warning" in the mailing lists:
>> 
>> <http://discourse.natecook.com/t/pitch-warning/1727 
>> <http://discourse.natecook.com/t/pitch-warning/1727>> (35)
>> 
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/thread.html
>>  
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/thread.html>>
>>  (11)
> 
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019407.html
>  
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019407.html>>
>  for the initial post.
> 
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/thread.html
>>  
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/thread.html>>
>>  (24)
> 
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019524.html
>  
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019524.html>>
>  for the initial post broken from the first part.

And:
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019545.html>
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019641.html
 
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019641.html>>
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019774.html
 
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019774.html>>
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019845.html
 
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019845.html>>

But the Discourse site contains most of these.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] #error

[Daryle Walker via swift-evolution]

> On Jun 12, 2017, at 8:03 AM, Ben Rimmington  wrote:
> 
> 
>> On 11 Jun 2017, at 19:15, Beta wrote:
>> 
>> A proposal and implementation of #warning exist.  It has been judged out of 
>> scope for Swift 3 and Swift 4 phase 2. 
>> 
>> https://github.com/apple/swift-evolution/pull/353
> 
> See also "[Pitch] #warning" in the mailing lists:
> 
>  (35)
> 
> 
>  (11)


 for the initial post.

> 
>  (24)

>
 for the initial post broken from the first part.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch] constexpr (i.e. compile-time constant expressions)

[Daryle Walker via swift-evolution]

I’m not a language/library designer, just a wannabe designer; I’m hitting the 
limits of my expertise. So unless I lucked out, one of the main designers will 
have to pick up this ball and clean it up. I’ll be here if you need 
clarification on stuff.

The seed of this idea was coming up with a equivalent to C++’s “static_assert” 
after someone querying me about “constexpr” in one of my array threads. Using 
these expressions during a generic where clause is like using C++ static-assert 
during template instantiation. Using them during an #if/#elseif/#else 
surrounding an #error directive (explained in a separate post a couple days 
ago) acts like using C++ static-asserts in non-template contexts. (This is what 
inspired the #error proposal.)

Arbitrary Compiler Constant Expressions
Proposal: SE- 
Authors: Daryle Walker , Author 2 

Review Manager: TBD
Status: Awaiting review
During the review process, add the following fields as needed:

Decision Notes: Rationale , 
Additional Commentary 
Bugs: SR- , SR- 

Previous Revision: 1 

Previous Proposal: SE- 
Introduction
This proposal adds compile-time constant expressions, and how to generate them, 
to the language

Swift-evolution thread: Discussion thread topic for that proposal 

Motivation
Conditional compilation blocks can shape the design of code based on criteria 
known at compile time. Generic where clauses do the same for limiting which 
generics can get instantiated. The criteria for either is extremely limited; 
Boolean combinations of environment state for conditional compilation blocks, 
and type equivalence, inheritance, or conformance for generic where clauses.

Other languages, like C++, allow values computed from specially-marked 
("constexpr") objects and functions. Adding this to Swift permits user-side 
generated tests today, and is a first step to non-Boolean compile-time values, 
like value-based generic parameters or static-sized array extents.

Proposed solution
Define a new declaration attribute that can mark off data and code as being 
compatible with compile-time expressions (CTE). The definitions of the marked 
items may have restrictions to ensure realization at compile-time.
Designate parts of certain constructs that they can only take CTEs. Expressions 
outside of those constructs are evaluated at run-time as usual.
Specify the compile-time realization engine.
Speculate on what parts of the existing standard library should be updated to 
support CTEs.
(I have no concrete examples here. But I do think about if we had something 
like C++'s type-traits library, then we could replace direct type-testing 
generic where clauses with ones that check the desired traits from our 
type-traits equivalent structure.)

Detailed design
Computation

The language to process the Swift source file for CTEs before compilation is... 
the compiler itself! The Swift compiler can translate Swift as a compiled 
language or an interpreted language. CTEs are computed in an interpreted pass 
of the source code. If the translation is a Swift interpretation, then the 
translation goes over the CTE directly instead of a second interpreter.

There cannot be any recursion. If the CTE is within a statement or part of a 
generic where clause, then the CTE cannot refer either directly or indirectly 
to the function its modifying. If the CTE is within an initializer, then it 
cannot refer to the object being initialized. A fatal diagnostic shall be 
emitted. One shall also be emitted if CTE evaluation reaches a nonreturning 
function, an uncaught exception, or dereferenced nil optional or similar.

Floating-point operations of the interpreter do not have to exactly match the 
ones from the compiler. The interpreter will make its best interpolation to a 
value supported by the compiler.

The directly-referred symbols of a CTE (the ones seen at the CTE-accepting 
construct) can only be constant declarations and/or routines that do not have 
inout parameters or mutating self. Constants have to be literals, top-level 
objects, or type-level properties. A type-level variable computed property can 
be used if it's getter-only.

Complier implementations may place restrictions on the complexity, resource 
usage, time taken, etc., of CTE evaluation. (Put reasonable minimal limits 
here.)

Attribute

The define attribute shall indicate its owning declaration can be included in 
CTEs. The corresponding definition must be available through the source code; 
the attribute is ignored for items with their realization only as binary code.

Such items still have their run-time realization, 

[swift-evolution] Swift phases and mis-timed proposals

[Daryle Walker via swift-evolution]

I’ve read about the Swift developers taking certain kinds of proposals during 
certain phases (Swift 3, Swift 4 stage 1, Swift 4 stage 2, etc.). So if someone 
writes a proposal that isn’t of the type of the current phase, it’s 
auto-rejected. Is it possible to set some kind of proposal queue so their 
authors don’t have to guess when it’s the right time to resubmit?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] [Pitch] #error

[Daryle Walker via swift-evolution]

> On Jun 10, 2017, at 2:00 PM, Xiaodi Wu  wrote:
> 
> Daryle, there have been several pitches in the past with respect to #error, 
> and very enlightening arguments both for and against the idea have been 
> eloquently written.
> 
> Since you’re resurrecting this idea, could I suggest going back through the 
> archives and linking to and summarizing these arguments, so that we’re not 
> restarting the discussion from scratch? :)

Is there somewhere to search the archives?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] [Pitch] #error

[Daryle Walker via swift-evolution]

Unconditional Error Messages
Proposal: SE- 
Authors: Daryle Walker , Author 2 

Review Manager: TBD
Status: Awaiting review
During the review process, add the following fields as needed:

Decision Notes: Rationale , 
Additional Commentary 
Bugs: SR- , SR- 

Previous Revision: 1 

Previous Proposal: SE- 
Introduction
This proposal adds the #error directive, which unconditionally posts a 
compile-time error.

Swift-evolution thread: Discussion thread topic for that proposal 

Motivation
A conditional compilation block permits branches of code based on the 
compilation conditions.

#if compilation condition 1
// statements to compile if compilation condition 1 is true
#elseif compilation condition 2
// statements to compile if compilation condition 2 is true
#else
// statements to compile if both compilation conditions are false
#endif
A block lets at most one of its branches to be incorporated into the compiled 
module. But compilation always occurs; there is no scenario to flag conditions 
that should never allow compiling.

When suspending work on a source file for a while, marking where you ended work 
with an unconditional error message would let the compiler remind you where you 
left off.

Proposed solution
The solution is to add a new compiler control statement, one that posts a fatal 
diagnostic during compilation. It can include a message to aid the user on how 
to change their code.

It's called #error, after the C preprocessor directive that has the same 
effects.

For example, instead of checking API compatibility at run-time:

guard #available(tvOS 1.0, *) else {
fatalError("We need a TV.")
}

// Do what we're supposed to do
We can move the check to compile-time:

#if os(tvOS)
// Do what we're supposed to do
#else
#error("We need a TV.")
#endif
Detailed design
Add to the "Grammar of a Compiler Control Statement":

compiler-control-statement → error-directive-statement­
Add a new section "Grammar of a Error Directive Statement":

error-directive-statement → #error ( static-string-literal )
The semantics of an error directive statement are: when such a statement is 
encountered during translation, and it is not in an inactive compilation block 
branch, compilation is aborted and the directive's string is included in the 
diagnostic of the directive's source line.

Source compatibility
This proposal should cause no problems with source compatibility. Relative to 
the current grammar, there is an addition of one token: #error. Since #-leading 
tokens are illegal except for the explicitly defined ones, there is no possibly 
of token overlap in legacy code.

Effect on ABI stability
Since the domain of this proposal is all in the compilation phase of creating 
object code, there is no effect on ABI stability.

Effect on API resilience
The domain of this proposal, controlling whether translation completes, does 
not affect any API.

Alternatives considered
The alternative is to do nothing. This would mean any checks would stay being 
delayed into run-time, and calling fatalError or similar functions to avoid 
implementing uncovered compilation cases.

The original C syntax left open tokens as the message after the #error token. I 
decided to enclose the message as a string to ease parsing.

Future directions
The original idea for this proposal was a distraction while bringing an 
adaptation of C++'s static_assert, as defined in its proposal 
. The 
static_assert is a condition-checking mechanic between assert and #error; Swift 
already has the former and this proposal would bring the latter. There'd still 
be no equivalent for static_assert. Another proposal for non-environment 
compile-time expressions and their use in generic where clauses would relieve 
most of need for static_assert, but there needs to be either a new construct a 
declaration-level version or #if/#elseif need to be allowed to access 
non-environment compile-time expressions.

Acknowledgements
How to Use the C Preprocessor's #error Directive 
 
by Nigel Jones

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

[Daryle Walker via swift-evolution]

> On Jun 9, 2017, at 12:14 AM, Yvo van Beek via swift-evolution 
>  wrote:
> 
> Typealiases can greatly reduce the complexity of code. But I think one change 
> in how the compiler handles them could make them even more powerful.
[SNIP]
> Perhaps it would be better if the extension would only apply to the parts of 
> my code where I use the HeaderKey typealias and not to all Strings. This 
> could be a great tool to specialize classes by creating a typealias and 
> adding functionality to it. Another example I can think of is typealiases for 
> dictionaries or arrays with added business logic through extensions 
> (especially since you can't inherit from structs).
> 
> If you want to create an extension that adds functionality to all Strings you 
> could have created an extension for String instead of HeaderKey.
> 
> Please let me know what you think. I'm not sure how complex this change would 
> be.
> I could write a proposal if you're interested.

Isn’t the point of “typealias" is that it does NOT have any change in 
semantics? The compiler doesn’t even have to acknowledge aliases in any 
run-time type tables, it just references the existing row of what the alias 
points to (based on a compile-time type table).

As others suggested, this new semantic could be moved to a new type concept 
(with a new keyword).

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] Fortran arrays and my recent proposal

[Daryle Walker via swift-evolution]

My array proposals included some form of specifying storage ranks for each 
extent. By default, the ranks would follow row-major order, like C. The first 
dimension would have the widest span between elements that differ by 1 in the 
first index and are the same for other indexes. The last dimension would have 
elements that differ by 1 in the last index and are the same for other indexes 
be adjacent in memory.

Overriding the ranks would change the numbers in the offset vector, which is 
combined with the index vector via the dot product to determine the memory 
offset of the desired element. The most common use for this is specifying 
column-major order, like Fortran. But recently I realized that I may have been 
too theoretical; Fortran-compatibility isn’t the most common use, but the only 
use. Is there any application for arbitrary storage ranks? (For N extents, 
there are N! possible storage ranks.) I’ve never heard of any other orders 
besides row- and column-majors.

You can implement column-major array indexing by reversing the order of indexes 
before dereference. This means if static-sized arrays get added to Swift, and 
value-based generic parameters and variadic generic parameters also get added, 
then a column-major array could be implemented as a library type. I think I’ll 
go with that, unless there’s a pressing need for column-major or 
arbitrary-ranked arrays out there.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Proposal: Always flatten the single element tuple

[Daryle Walker via swift-evolution]

> On Jun 7, 2017, at 11:12 PM, Stephen Celis via swift-evolution 
>  wrote:
> 
>> On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> However, what I don’t get is why you’d have a mismatch here. Your method 
>> `first` accepts a closure, and surely the type it expects should be 
>> `((String, Conversation)) -> Bool` instead, since that is the type that the 
>> `filter` method expects in the body of your implementation?
> 
> I must continue to ask for more justification as to why it's _so_ valuable to 
> consider "(Int,Int)->()" and "((Int,Int))->()" to be different in _most_ 
> cases. Even in the contrived-described example above, the function may be 
> reusable and the engineer may pass "String" and "Conversation" objects 
> directly in some cases, and this distinction only makes things more difficult 
> and requires cumbersome workarounds.

Imagine if “(Int, Int)” was hidden behind a type-alias. You expect you’d be 
entering a single argument. But, surprise, you unintentionally activated the 
secret tuple-exploding mode and you’re actually passing in two arguments!

[I didn’t follow the original discussion, so apologies if using a type-alias 
doesn’t case tuple-explosion. Of course, that would be a different code smell….]

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] Indexing (static-size) arrays: offsets or tables?

[Daryle Walker via swift-evolution]

I looked up a history of programming languages on Wikipedia, and looked up a 
bunch of them that I heard of to see how they handle array indexing.

1. A lot of them do it the way C does it: you specify a positive integer at the 
spot where you give a dimension. Then at dereference-time, you insert an 
integer in 0..___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Yet another fixed-size array spitball session

[Daryle Walker via swift-evolution]

> On Jun 2, 2017, at 10:26 AM, Dave Abrahams via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> on Fri Jun 02 2017, Brent Royal-Gordon <swift-evolution@swift.org 
> <mailto:swift-evolution@swift.org>> wrote:
> 
>>> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Static-Sized Arrays
>> 
>> My preference would still be to build this from four separate features:
>> 
>> 1. Magic tuple conformances: We already want to be able to
>> automatically conform tuples to protocols like Equatable, Hashable,
>> and Comparable. These can all be compiler magic; they don't have to be
>> definable in userspace.
>> 
>> 2. Conform tuples to Collection: The Element type should be the most
>> specific common supertype of the tuple's elements. If all the elements
>> are the same type, it would be that type. The Index and IndexDistance
>> types should be Int.
>> 
>> 3. Conform same-type tuples to MutableCollection: If all elements are
>> the same type, you can also modify the values. (If their types vary in
>> any way, however, it would not be safe to allow mutations, since you
>> could assign the wrong type to an element.)
>> 
>> 3. Add sugar for a tuple of N identical elements: Probably something
>> like `4 * Int`, but opinions can vary.

Static-sized arrays should not be shoved into being a tuple with funny 
settings; that introduces subtleties into the tuple concept only because of 
jammed-in array support. The fact 3 separate-proposal-worthy features need to 
be introduced first, in which at least one is dubious in value (#2, since a lot 
of times the common type would be “Any”), should be a code smell on this 
approach.

> I think any complete solution depends on at least two more things:
> 
> 1. adding the ability to get an UnsafePointer to an immutable instance
>   of value type

Do you mean something besides applying the address-of operator (I’m not sure 
what that is.) to “myArray.0”?

What are you thinking of doing with such unsafe-pointers? In this thread, I had 
“array of T” or “[of T]” to make array-segment references, so you can make a 
function that can take an array of a certain type without specializing for each 
shape. (Worse, since we only have type-based generic parameters, we couldn’t 
generate such functions.) It’s the same as using “T[]” as a function parameter 
type in C.

While thinking of this response, I looked at the same section of SwiftDoc.org 
<http://swiftdoc.org/> for UnsafePointer, and there were 
Unsafe(Mutable)BufferPointer. These types do the same job as my theoretical 
“[of T]”, so maybe I should defer to those. We would add a global function to 
convert given arrays to unsafe-buffer-pointers.

> 2. support for leaving some of the elements uninitialized, or
>   alternatively, a variation of this type that is RangeReplaceable but
>   also bounded in capacity.

AFAIK, all objects have to be fully initialized before the first read. If 
that’s the case, then skipping element initialization (which I can understand 
wanting when using a large array for a mathematical matrix type) would require 
a separate proposal, since we would need a full consideration of the 
consequences. (What happens when reading an uninitialized element?) For the 
variant, couldn’t that be implemented with a library type (since you need a 
per-object list of current elements), maybe using the base array type as a 
generic parameter.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[swift-evolution] Can functions/methods be overloaded on mutability of parameters?

[Daryle Walker via swift-evolution]

Can I make two overloads such that one can take an argument from a “let”-mode 
object or a regular function parameter and return an UnsafePointer and then 
have the other take a “var”-mode object or inout function parameter and return 
an UnsafeMutablePointer? I think this can be done in C++.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Sparse (fixed-size) array literal syntax

[Daryle Walker via swift-evolution]

> On Jun 2, 2017, at 4:06 AM, Jaden Geller  wrote:
> 
> I don’t know if you’re aware, but you can extend arbitrary nominal types with 
> literal syntax.
> 
> ```
> extension FixedSizedArray: ExpressibleAsDictionaryLiteral { … }
> ```
> 
> Nothing special needs to be done on the implementation side to make this 
> possible. If fixed sized arrays are not nominal types (like tuples, unlike 
> `Array`s), then you will only be able to give this sugar to types that wrap 
> them, not the type itself (w/o special support).

I don’t think that’ll work with the “where” clauses and “default” values in the 
new syntax.

> What’s the discussion on enhanced array and dictionary literals? I think I 
> missed that.

This is the discussion. I’m asking if this “enhanced array” syntax I just came 
up with would interfere with the existing dictionary syntax from a parsing 
perspective.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] Yet another fixed-size array spitball session

[Daryle Walker via swift-evolution]

New Spitball

But first:

C has one of the worst array presentation models. It has traumatized so many 
that those among them that grew up to be language designers themselves threw 
out fixed-sized arrays entirely (from Java to even current Swift!). But we’re 
getting through to everyone that the concept is still important, no matter how 
bad one realization of it is.

* If you could to arrays over, why limit your indexes to 0 ..< COUNT, when you 
could use any range by subtracting an offset first
* Once you do that, why limit yourself to Int, when anything that could be 
implemented as an Int (like an enumeration type) would also work.

The whole point of adding types is abstraction. If you are modeling a table 
where the coordinates are an enumeration, why not let the language to the 
translation for you. There’s no need for just a Swift-y version of C’s array 
model. (Already Swift downplays pointers, so the “arrays are pointers with 
funny settings” part of the C model shouldn’t be carried over.)

This isn’t a new concept; while C’s successors gave up, C’s contemporaries 
didn’t. There’s plenty of models to base array presentation on. Looking at an 
Ada page recently, I realized that I must have let my previous experience shape 
the keywords I chose.

Now back to Spitball #3:

New Keywords:
* of
* #indexOf
* #flatten

Static Array Directive:
* “[“ Specifiers_opt “of” type “]”
* Specifiers: Specifier | Specifier “,” Specifiers
* Specifier: Extent-Range Storage-Rank_opt
* Extent-Range: Low … High | Low ..< High | N (for 0 ..< N) | Enum-Type (for 
Enum.min … Enum.max)
* Storage-Rank: Integer in 0 ..< ExtentCount; use smallest unused value if 
missing; all values must be used exactly once
* “mutating” (or “nonmutating”) can precede the type if the directive is used 
for an array-segment reference

Immediate Array: Use Static Array Directive with at least one extent

Array-Segment Reference: Use Static Array Directive with no extents
* can initialize a scoped reference with an array literal, but the reference 
must be in “let” mode (so you can’t reseat it and lose the only reference to 
the array)
* If you use this construct, put in a “mutating” to let the elements be 
changeable if needed
* This will let you use a C-like “let myArray: [of mutating Int] = [1, 2, 3, 4, 
6]” without counting first, like “var myArray: [5 of Int] = [1, 2, 3, 4, 6]” 
would need

Nominal Arrays: Use “struct” with a Static Array Directive as the base type; 
mutually exclusive with instance-level stored properties (Having neither is OK.)
* The “subscript” definition allows zero parameters, but “[]” doesn’t allow 
zero arguments, so use “myArray.super” to get the inner singular value in this 
case
* Swift allows “self” by itself, but not “super”. This will have to be changed.

For loops:
* Array-segment references conform to RandomAccessCollection (and possibly 
MutableCollection); the two definitive array types don’t
* For loops will work for the definitive array types anyway
* We should either define iteration in storage order or let it be 
implementation-defined
* We should have some other syntax to let processing of elements go in parallel
* Within a for-loop, use “#indexOf(X)” to get a tuple of the index coordinates 
of the current element; “X” is (one of) the iteration objects between the “for” 
and “in”; an identifier is needed so if you have nested for-loops with separate 
arrays, you can choose which one to inspect

Dereferencing:
* For immediate arrays, use "myArray.0" like tuples, it’s "myArray.(1, 2)" for 
multi-dimensional arrays
* Convert to array-segment first if you need run-time index selection (with 
“[]”)
* Nominal arrays come with “[]” by default

Function arguments:
* Use array-segment reference parameter to take definitive arrays of any size, 
assuming the same element type
* If the definitive array is multi-dimensional, use “#flatten(myArray)” first 
(I’ve realized that a multi-D array should not translate to a linear ASR 
silently by default.)
* Of course, you can use either definitive array type as a parameter too

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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