date:20171002

> On Oct 2, 2017, at 10:57 PM, Chris Lattner  wrote:
> 
> 1) Why not another level of access control?  There is a reasonable argument 
> that what you’re doing is making something “more public than public” or that 
> you’re making the “body also public”.  I’m not strongly in favor of this 
> design approach, but if you agree, the doc should explain why you’re not in 
> favor of it.

Oh, I forgot to address this point. I’m against this because even though this 
proposal says inlinable requires public, it is really orthogonal to public, 
because eventually we will have something like the current @_versioned 
attribute, where internal (or even private, as some have suggested) functions 
can be “public ABI”. For example,

@_versioned func myInternalDetails() {
  // …
}

@inlinable
public func myPublicFunction() {
  myInternalDetails() // I can reference this from an inlinable function, but 
users can’t call it directly
}

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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 11:11 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
>> This semantic doesn’t make sense to me, and I think we need to change it.  I 
>> think we are better served with the semantics of “the body may be inlined, 
>> but doesn’t have to.”
> 
> That is the effect it has today. The decision to inline or not is made by the 
> optimizer, and @inlinable doesn’t change anything here; it makes the body 
> available if the optimizer chooses to do so.

Also remember we have the @inline(never) attribute. It’s not underscored so I’m 
assuming it’s an “official” part of the language. And "@inline(never) 
@inlinable" is a perfectly valid combination — it serializes the SIL for the 
function body, and while inlining it is prohibited, it is still subject to 
specialization, function signature optimizations, etc.

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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Thanks for the review!

> On Oct 2, 2017, at 10:57 PM, Chris Lattner  wrote:
> 
> This is a great proposal, I’m a strong supporter, but have one question and 
> one strong push back:
> 
>> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Introduction
>> We propose introducing an @inlinable attribute which exports the body of a 
>> function as part of a module's interface, making it available to the 
>> optimizer when referenced from other modules.
>> 
> The major question I have is “why yet another attribute”.  The thread about 
> exhaustive/extensible enums is similarly proposing introducing another 
> one-off way to be enums fragile, and this is directly related just for 
> function-like things.
> 
> I’d love to see rationale in the proposal for why you’re not taking this in 
> one of these directions:
> 
> 1) Why not another level of access control?  There is a reasonable argument 
> that what you’re doing is making something “more public than public” or that 
> you’re making the “body also public”.  I’m not strongly in favor of this 
> design approach, but if you agree, the doc should explain why you’re not in 
> favor of it.
> 
> 2) Why can’t we have a single Swift-wide concept that unifies all of the 
> resilience ideas under a single umbrella like “fragile” - which indicates 
> that the body of a declaration is knowable to clients?  There is a very 
> reasonable holistic design where “fragile public func” makes its body 
> inlinable, and “fragile enum” similarly makes the cases knowable to the 
> client (thus making exhaustive switching a possibility).  I am strongly in 
> favor of this approach.  
> 
> 
> In any case, even if you’re opposed to these approaches, I’d love for the 
> “alternatives considered” section to indicate what the objection is.  I am 
> really very concerned that you’re causing a keyword/attribute explosion and 
> conceptual complexity by adding too many small things to individual parts of 
> the language.  We would ideally have a simple and holistic solution to 
> resilience.

I agree with that keyword/attribute explosion is a concern. We also plan on 
submitting a proposal to add a @fixedContents attribute for structs (currently 
implemented as @_fixed_layout) which enables more efficient access patterns in 
resilient code, for example direct access of stored properties, at the cost of 
preventing new stored properties from being added in a binary-compatible 
manner. So we would have ‘nonexhaustive’ enums, @fixedContents structs, and 
@inlinable functions/properties/initializers.

Perhaps it makes sense to have a single ‘fragile’ keyword replace 
@fixedContents and @inlinable. For enums, ‘nonexhaustive’ does “feel” a bit 
different, so perhaps it makes sense for it to be its own thing. From an 
implementation perspective it doesn’t really matter if we have multiple 
attributes or one, so of course I’d prefer to go with the approach that makes 
the most sense to people language design-wise.

> This semantic doesn’t make sense to me, and I think we need to change it.  I 
> think we are better served with the semantics of “the body may be inlined, 
> but doesn’t have to.”

That is the effect it has today. The decision to inline or not is made by the 
optimizer, and @inlinable doesn’t change anything here; it makes the body 
available if the optimizer chooses to do so.

> 2) there are lots of reasons why the compiler may not *want* to inline the 
> body of a declaration, including wanting fast debug builds, “optimizing for 
> size” builds, or cost heuristics that lead the compiler to believe that there 
> is no gain for inlining the body of a function in some context.

Right.

> 3) If the symbol is always guaranteed to be present, adding @inlinable is an 
> ABI preserving change.  I think that this is also really important because it 
> reflects a natural evolution of code: in R1 of a module’s public release, a 
> symbol my be public, but after numerous releases, it may be decided that it 
> is stable enough to make “inlinable”.
> 
> 4) Certain declarations *have* to be emitted anyway, e.g. an @inlinable open 
> method on a class can’t actually be inlined in most cases, because the call 
> is dynamicly dispatched.

Yes. The function is still emitted into the library, but the symbol does not 
have public linkage. If we make the change to give the attribute ‘always emit 
into client’ semantics, a client can still reference the function without 
inlining it, for whatever reason, either because it cannot be (you’re using the 
function as a value) or the optimizer decides that it is not profitable to 
inline it. However the client binary would have to emit its own copy of the 
function (again, with non-public linkage).

>> We have discussed adding a "versioned @inlinable" variant that preserves the 
>> public entry point for older clients, while making the declaration inlinable 
>> for newer clients. This will likely be a se

Re: [swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

2017-10-02 Thread Andrew Trick via swift-evolution



> On Sep 30, 2017, at 10:45 AM, Taylor Swift  wrote:
> 
> this function initializeMemory(as:from:) says it will be 
> removed in Swift 4.0. It is now Swift 4.0. can I remove it?

It looks safe to remove. However, the doc comments in the same file should be 
updated to refer to `initializeMemory(as:from:count:)`.

+cc Nate Cook

-Andy

> On Sat, Sep 30, 2017 at 2:15 AM, Taylor Swift  > wrote:
> 
> 
> On Thu, Sep 28, 2017 at 7:59 PM, Andrew Trick  > wrote:
> 
>> On Sep 6, 2017, at 10:15 PM, Taylor Swift > > wrote:
>> 
>> okay so I think so far what’s been agreed on is 
>> 
>> 1. rename “Bytes” to “Memory” in the raw pointer API. Note: this brings the 
>> `copyBytes(from:)` collection method into the scope of this proposal
>> 
>> 2. change raw offsets to be in terms of bytes, not typed strides. This 
>> argument will be called `atByteOffset:` and will only appear in 
>> UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in 
>> UnsafeMutableRawPointer, since we can just use pointer arithmetic now.
>> 
>> 
>> 3. move UnsafeMutableBufferPointer’s `at:` arguments to the front of the 
>> parameter list. mostly cause any pointer arithmetic happens in the front so 
>> structurally we want to mirror that.
>> 
>> 4. add dual (to:) single element initializers and assigners to 
>> UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s 
>> apparently not useful there. 
>> `UnsafeMutableRawPointer.initializeMemory(as:repeating:count:)` still 
>> loses its default count to prevent confusion with its buffer variant.
>> 
>> 5. memory deallocation on buffer pointers is clearly documented to only be 
>> defined behavior when the buffer matches a whole heap block. 
> 
> 
> Kelvin,
> 
> Attempting to limit the scope of this proposal backfired. I was hoping to 
> avoid discussing changes to the slice API, instead providing basic 
> functionality within the buffer API itself. However, Dave Abrahams has argued 
> that once the slice API is extended, the positional arguments are extraneous 
> and less clear.
> 
> Instead of
> 
>   buf.intialize(at: i, from: source)
> 
> We want to force a more obvious idiom:
> 
>   buf[i.. 
> I think this is a reasonable argument and convinced myself that it's possible 
> to extend the slice API. I'm also convinced now that we don't need overloads 
> to handle an UnsafeBufferPointer source, instead we can provide a single 
> generic entry point on both UnsafeMutableBufferPointer and its slice, 
> optimized within the implementation:
> 
>  `initialize(from: S) -> (S.Iterator, Index)
> 
> We can always drop down to the UnsafePointer API to get back to a direct 
> unsafe implementation as a temporary workaround for performance issues.
> 
> Let's set aside for now whether we support full or partial 
> initialization/assignment, how to handle moveInitialize, and whether we need 
> to return the Iterator/Index. This is going to require another iteration on 
> swift-evolution, which we should discuss in a separate thread. 
> 
> At this point, I suggest removing the controversial aspects of SE-0184 so 
> that we can put the other changes behind us and focus future discussion 
> around a smaller follow-up proposal.
> 
> Here I've summarized the changes that I think could be accepted as-is:
> https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e 
> 
> 
> If you amend SE-0184 accordingly and file a new PR, I think it can be quickly 
> approved.
> 
> -Andy
> 
> 
> Part one of SE-0184 is here as SE-0184 A 
> 
>  
> I’ll implement it tomorrow and then make the PR
> 

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

Re: [swift-evolution] superscripts, subscripts, etc.

2017-10-02 Thread Chris Lattner via swift-evolution


> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution 
>  wrote:
> 
> Chris Lattner wrote:
> 
>> Just FWIW, IMO, these make sense as operators specifically because they are 
>> commonly used by math people as operations that transform the thing they are 
>> attached to.  Superscript 2 is a function that squares its operand.  That 
>> said, perhaps there are other uses that I’m not aware of which get in the 
>> way of the utilitarian interpretation.
> 
> But there are SO MANY uses for superscripts, subscripts, and other such 
> annotations, and they are all context specific, just in math, without getting 
> into chemistry, physics, statistics, and so forth.
> 
> They’re really more like methods on the object to which they’re attached, or 
> the combination of a method and an argument.  

I agree.

> Wouldn’t classing them as identifiers lend itself better to this?

No, making them an operator is better for this usecase.

You want:

x²  to parse as “superscript2(x)” - not as an identifier “xsuperscript2” which 
is distinct from x.

-Chris

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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

2017-10-02 Thread Chris Lattner via swift-evolution

This is a great proposal, I’m a strong supporter, but have one question and one 
strong push back:

> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution 
>  wrote:
> Introduction
> We propose introducing an @inlinable attribute which exports the body of a 
> function as part of a module's interface, making it available to the 
> optimizer when referenced from other modules.
> 
The major question I have is “why yet another attribute”.  The thread about 
exhaustive/extensible enums is similarly proposing introducing another one-off 
way to be enums fragile, and this is directly related just for function-like 
things.

I’d love to see rationale in the proposal for why you’re not taking this in one 
of these directions:

1) Why not another level of access control?  There is a reasonable argument 
that what you’re doing is making something “more public than public” or that 
you’re making the “body also public”.  I’m not strongly in favor of this design 
approach, but if you agree, the doc should explain why you’re not in favor of 
it.

2) Why can’t we have a single Swift-wide concept that unifies all of the 
resilience ideas under a single umbrella like “fragile” - which indicates that 
the body of a declaration is knowable to clients?  There is a very reasonable 
holistic design where “fragile public func” makes its body inlinable, and 
“fragile enum” similarly makes the cases knowable to the client (thus making 
exhaustive switching a possibility).  I am strongly in favor of this approach.  

In any case, even if you’re opposed to these approaches, I’d love for the 
“alternatives considered” section to indicate what the objection is.  I am 
really very concerned that you’re causing a keyword/attribute explosion and 
conceptual complexity by adding too many small things to individual parts of 
the language.  We would ideally have a simple and holistic solution to 
resilience.

> Effect on ABI stability
> 
> The introduction of the @inlinable attribute does not change the ABI of 
> existing declarations. However, adding @inlinable to an existing declaration 
> changes ABI, because the declaration will no longer have a public entry point 
> in the generated library. Removing @inlinable from an existing declaration 
> does not change ABI, because it merely introduces a new public symbol in the 
> generated library.
> 
This semantic doesn’t make sense to me, and I think we need to change it.  I 
think we are better served with the semantics of “the body may be inlined, but 
doesn’t have to.”  This corresponds to available_externally linkage in LLVM, 
 and is provided by GNU89 
"extern inline".

Here are 5 reasons:

1) the current spelling: "@inlinable” implies that the body “may” be inlined, 
not that it “must” be inlined.

2) there are lots of reasons why the compiler may not *want* to inline the body 
of a declaration, including wanting fast debug builds, “optimizing for size” 
builds, or cost heuristics that lead the compiler to believe that there is no 
gain for inlining the body of a function in some context.

3) If the symbol is always guaranteed to be present, adding @inlinable is an 
ABI preserving change.  I think that this is also really important because it 
reflects a natural evolution of code: in R1 of a module’s public release, a 
symbol my be public, but after numerous releases, it may be decided that it is 
stable enough to make “inlinable”.

4) Certain declarations *have* to be emitted anyway, e.g. an @inlinable open 
method on a class can’t actually be inlined in most cases, because the call is 
dynamicly dispatched.
> We have discussed adding a "versioned @inlinable" variant that preserves the 
> public entry point for older clients, while making the declaration inlinable 
> for newer clients. This will likely be a separate proposal and discussion.
> 
5) It eliminates this complexity.

> Comparison with other languages
> The closest language feature to the @inlinable attribute is found in C and 
> C++. In C and C++, the concept of a header file is similar to Swift's binary 
> swiftmodule files, except they are written by hand and not generated by the 
> compiler. Swift's public declarations are roughly analogous to declarations 
> whose prototypes appear in a header file.
> 
> Header files mostly contain declarations without bodies, but can also declare 
> static inlinefunctions with bodies. Such functions are not part of the binary 
> interface of the library, and are instead emitted into client code when 
> referenced. As with @inlinable declarations, static inlinefunctions can only 
> reference other "public" declarations, that is, those that are defined in 
> other header files.
> 
The writing should be clarified, because there are multiple concepts going on 
here, including GNU89’s notion of inline, C99’s notion of inline (aka extern 
inline), and static inline, each with overlapping but and confusingly different 
semantics.

-Chr

[swift-evolution] superscripts, subscripts, etc.

2017-10-02 Thread John Payne via swift-evolution

Chris Lattner wrote:

> Just FWIW, IMO, these make sense as operators specifically because they are 
> commonly used by math people as operations that transform the thing they are 
> attached to.  Superscript 2 is a function that squares its operand.  That 
> said, perhaps there are other uses that I’m not aware of which get in the way 
> of the utilitarian interpretation.

But there are SO MANY uses for superscripts, subscripts, and other such 
annotations, and they are all context specific, just in math, without getting 
into chemistry, physics, statistics, and so forth.

They’re really more like methods on the object to which they’re attached, or 
the combination of a method and an argument.  Wouldn’t classing them as 
identifiers lend itself better to this?

Apologies in advance if this is a waste of everyone’s time.

- John Payne

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Mon, Oct 2, 2017 at 11:12 PM, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

> Maybe they've started teaching it earlier than when I went through
> school... I don't think I learned it until Discrete Math, which IIRC was a
> 2nd or 3rd year course at my college and only required for Math, CS, and
> maybe EE majors. Anyway, WRT a), if Swift achieves its "take over the
> world" goal, *all* use cases will be Swift use cases. WRT b), "many" as
> in the numerical quantity or "many" as in the percentage? There are
> probably millions of people who recognize calculus's operators, but there
> are 7.5 *billion* people in the world.
>

I’m 19 and for what it’s worth, set notation is “taught” in 9th grade but
no one really “learns” it until they get to discrete structures in college.
There’s a ton of random things that get introduced in high school/middle
school that no one ever retains. Believe it or not they teach set closure
in 6th grade, at least in my state.

It’s still my opinion that ⊆, ⊇, ∪, and friends make for obfuscated code
and I consider unicode operators to be one of the “toy” features of Swift.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

2017-10-02 Thread Chris Lattner via swift-evolution

On Oct 2, 2017, at 5:33 PM, Jordan Rose  wrote:
>> 
>> Don't you think this is not normal situation and actually there IMO can't be 
>> any reason to keep this bug-producing inconsistency in Swift? (especially 
>> given Swift 5 seems like is a last moment to fix this)
> 
> I hate to say it but I'm inclined to agree with Vladimir on this. "private 
> extension" has a useful meaning now distinct from "fileprivate extension", 
> and it was an oversight that SE-0169 
> 
>  didn't include a fix here. On this very narrow, very specific access control 
> issue I think it would still be worth discussing; like Xiaodi said it's not 
> related to James' original thread-starter.

Ok, I admit I just didn’t want to think about access control anymore after 
laster year’s excitement :-)

That said, it seems that there is broad support for considering a refinement 
here, and I’m happy to get out of the way and let you guys make Swift better. 
:-)  Thanks!

-Chris


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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

again, i should reiterate, most users aren’t compiler engineers and so most
people use access modifiers as a means of code organization. being able to
diagnose when a “private” symbol is being referenced from somewhere it
shouldn’t be is very important; the linking and mangling details should be
handled by the compiler underneath all of that.

On Mon, Oct 2, 2017 at 11:45 PM, Slava Pestov  wrote:

>
> On Oct 2, 2017, at 9:15 PM, Xiaodi Wu  wrote:
>
>
> On Mon, Oct 2, 2017 at 22:23 Slava Pestov  wrote:
>
>> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu  wrote:
>>
>> On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov  wrote:
>>
>>>
>>> On Oct 2, 2017, at 7:52 PM, Kelvin Ma  wrote:
>>>
>>> Is this only a problem with fileprivate or does it extend to private
>>> members too? I feel like this would be a very valuable feature to support.
>>>
>>>
>>> Private members too. Consider this example,
>>>
>>> struct S {
>>>   private func f() {}
>>> }
>>>
>>> The member S.f mangles as _T06struct1SV1f33_
>>> AB643CAAAE0894CD0BC8584D7CA3AD23LLyyF. In this case, I suppose we won’t
>>> need the private discriminator because there can only be one S.f that’s
>>> directly a member of S, and not an extension. However imagine if two
>>> different source files both defined extensions of S, with a private member
>>> f. You would need to disambiguate them somehow.
>>>
>>
>> The simple-minded way to do this would be to require @_versioned
>> annotations on private and fileprivate members to supply an internally
>> unique alternative name to be used for mangling-as-though-internal (i.e.
>> `@_versioned(my_extension_f)`). Such a function becoming public in an
>> ABI-compatible way would require renaming the "actual" name to the unique
>> @_versioned name.
>>
>>
>> We have _silgen_name for that, but we really don’t want to expose this
>> more generally because people have been abusing it to make things visible
>> to C, and they should be using @_cdecl instead.
>>
>
> The difference here would be that the "@_versioned name" would be subject
> to mangling. It's essentially equivalent to a way of specifying a custom
> discriminator to be hashed so that the source file name is omitted and not
> ABI. Not that I think it'd be elegant, but it would not be abusable like
> _silgen_name.
>
>
> That wouldn’t solve the problem where removing @_versioned(name) and
> adding public would change the symbol’s name.
>
> However, your idea of mangling versioned private symbols like internal and
> diagnosing conflicts might be workable.
>
> Slava
>
>
>
>> A more elegant refinement could be to have @_versioned private and
>> fileprivate members mangled as though internal, erroring if two or more
>> members with the same name are both @_versioned--would that work?
>>
>>
>> If you’re going to do that what is the value in having the capability at
>> all?
>>
>
> Solely to have some way of preventing members in one file from calling
> members in another file at compile time.
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

2017-10-02 Thread Chris Lattner via swift-evolution

On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution 
 wrote:
>> Keep in mind that Swift already goes far above and beyond in terms of 
>> operators
> Yep, that's is a large part of why I'm such a Swift fan :-D

Fortunately, no one is seriously proposing a major curtailing of the 
capabilities here, we’re just trying to rationalize the operator set, which is 
a bit of a mess at present.

>> in that: (a) it allows overloading of almost all standard operators; (b) it 
>> permits the definition of effectively an infinite number of custom operators 
>> using characters found in standard operators; (c) it permits the definition 
>> of custom precedences for custom operators; and (d) it additionally permits 
>> the use of a wide number of Unicode characters for custom operators. Most 
>> systems programming languages don't even allow (a), let alone (b) or (c). 
>> Even dramatically curtailing (d) leaves Swift with an unusually expansive 
>> support for custom operators.

> Yes, but many of those custom operators won't have a clear meaning because 
> operators are rarely limited to pre-existing symbols like "" (which 
> doesn't mean anything at all AFAIK), so operators that are widely known 
> within some field probably won't be widely known to the general public, 
> which, IIUC, seems to be your standard for inclusion(?). Please let me know 
> if that's not your position... I hate being misunderstood probably more than 
> the next person, and I wouldn't want to be guilty of that myself.

The approach to operator handling in Swift is very intentional.  IMO, it is 
well known that:

1) Operators can make code significantly easier to understand by reducing noise 
from complex expressions: writing x.matmul(y) is insane 
 if you’re doing a lot of matrix 
multiplies.
2) Operators can be completely opaque to someone who doesn’t know them, and 
sometimes named functions are more clear.
3) Named functions can also sometimes be completely opaque if you don't know 
them, e.g. "let x = cholesky(y)"
4) Languages with fixed operator sets that also allow overloading (e.g. C++) 
end up with those operators being abused.
5) Some code can only be written and maintained by domain experts, and those 
experts often know the operators.

Swift’s approach is basically to say to users: “ok we allow overloaded 
operators, but at least if you encounter some operation that you don’t know… 
you know that you don’t know it”.  If you encounter "if ¬x {“  or “a ∩ b” in 
some source code, at least you can command click, jump to the definition and 
read what it does: you aren’t misled into thinking that the expression is some 
familiar thing, but find out later it was overloaded to do something crazy 
(bitshifts for i/o?  really??? :).

Set algebra is an illustrative example, because it is both used by people who 
are experts and people who are not.  As far as policies go, I think it makes 
sense for Swift libraries to define operator-like things as named functions 
(e.g. “intersection") and also define operators (“∩”) which can optionally be 
used in source bases that want them for convenience.  The compiler and language 
cannot know whether a code base is written and maintained by experts who know 
the symbols and who value their clarity (over the difficulty typing and 
recognizing them), and this approach allows maintainers of the codebase to pick 
their own policies.

I do think that Ethan’s suggestion upthread interesting, which suggest 
considering something like:
   import matrixlib (operators: [ᵀ,·,⊗])

Three concerns I see:
 - Requiring them today would be a source incompatibility with Swift 4
 - Multiple modules can define operators, unclear whether this refers to the 
operator decl or implementations of operators.
 - Imports are per-module, not per-source-file, so this couldn’t be used to 
“user-partition” the identifier and operator space.  It could be a way to make 
it clear that the user is opting into these explicitly.

-Chris

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

2017-10-02 Thread David Hart via swift-evolution



> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
 On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
  wrote:
 
 On 01.10.2017 1:18, Chris Lattner wrote:
>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Vladimir, I agree with you on that change, but it’s a separate topic 
>> from this one.
>> 
>> Tony is absolutely correct that this topic has already been discussed. 
>> It is a deliberate design decision that public types do not 
>> automatically expose members without explicit access modifiers; this has 
>> been brought up on this list, and it is clearly not in scope for 
>> discussion as no new insight can arise this late in the game. The 
>> inconsistency with public extensions was brought up, the proposed 
>> solution was to remove modifiers for extensions, but this proposal was 
>> rejected. So, the final design is what we have.
> Agreed.  The core team would only consider a refinement or change to 
> access control if there were something actively broken that mattered for 
> ABI stability.
 
 So we have to live with *protected* extension inconsistency for very long 
 time just because core team don't want to even discuss _this particular_ 
 inconsistency(when access level in *private extension* must be private, 
 not fileprivate)?
 
 Yes, we decided that access level for extension will mean a default and 
 top most access level for nested methods, OK. But even in this rule, which 
 already differ from access modifiers for types, we have another one 
 special case for 'private extension'.
 
 Don't you think this is not normal situation and actually there IMO can't 
 be any reason to keep this bug-producing inconsistency in Swift? 
 (especially given Swift 5 seems like is a last moment to fix this)
>>> 
>>> I hate to say it but I'm inclined to agree with Vladimir on this. "private 
>>> extension" has a useful meaning now distinct from "fileprivate extension", 
>>> and it was an oversight that SE-0169 didn't include a fix here. On this 
>>> very narrow, very specific access control issue I think it would still be 
>>> worth discussing; like Xiaodi said it's not related to James' original 
>>> thread-starter.
>> 
>> I agree with this in principle but would not want to see it become a 
>> slippery slope back into extremely long access control discussions.
>> 
> 
> As I've said elsewhere, I too agree with this in principle. I agree with 
> Jordan that the current state of things is justifiable but the alternative 
> would be somewhat superior, agree that in a vacuum this very narrow and 
> specific discussion might be warranted, and agree also that this could be a 
> very slippery slide down a very steep slope.

Same here. It’s the only grudge I have left with the current access control 
situation. I remember Doug Gregor and John McCall discussing this during the 
last access control proposal. And I wouldn’t mind having a very narrow 
discussion about only this.

I organize my types into extensions for each conformance and for each access 
control. I can currently implicitly apply public or fileprivate to all members 
of an extension but I have no way of doing the same for private. That’s why I 
think it should be fixed.

>>> 
>>> (I maintain that the current model does not include a special case; it 
>>> simply means the 'private' is resolved at the level of the extension rather 
>>> than the level of its members. But that isn't what people expect and it's 
>>> not as useful.)
>>> 
>>> 
>>> I agree that changing the behavior of all access modifiers on extensions is 
>>> out of scope. (I also agree that it is a bad idea. Sorry, James, but 
>>> wanting 'pubic' here indicates that your mental model of extensions does 
>>> not match what Swift is actually doing, and that could get you into 
>>> trouble.)
>>> 
>>> Jordan
>>> 
>>> ___
>>> 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 mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Cross-module inlining and specialization


> On Oct 2, 2017, at 9:15 PM, Xiaodi Wu  wrote:
> 
> 
> On Mon, Oct 2, 2017 at 22:23 Slava Pestov  > wrote:
>> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu > > wrote:
>> 
>> On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov > > wrote:
>> 
>>> On Oct 2, 2017, at 7:52 PM, Kelvin Ma >> > wrote:
>>> 
>>> Is this only a problem with fileprivate or does it extend to private 
>>> members too? I feel like this would be a very valuable feature to support.
>> 
>> Private members too. Consider this example,
>> 
>> struct S {
>>   private func f() {}
>> }
>> 
>> The member S.f mangles as 
>> _T06struct1SV1f33_AB643CAAAE0894CD0BC8584D7CA3AD23LLyyF. In this case, I 
>> suppose we won’t need the private discriminator because there can only be 
>> one S.f that’s directly a member of S, and not an extension. However imagine 
>> if two different source files both defined extensions of S, with a private 
>> member f. You would need to disambiguate them somehow.
>> 
>> The simple-minded way to do this would be to require @_versioned annotations 
>> on private and fileprivate members to supply an internally unique 
>> alternative name to be used for mangling-as-though-internal (i.e. 
>> `@_versioned(my_extension_f)`). Such a function becoming public in an 
>> ABI-compatible way would require renaming the "actual" name to the unique 
>> @_versioned name.
> 
> We have _silgen_name for that, but we really don’t want to expose this more 
> generally because people have been abusing it to make things visible to C, 
> and they should be using @_cdecl instead.
> 
> The difference here would be that the "@_versioned name" would be subject to 
> mangling. It's essentially equivalent to a way of specifying a custom 
> discriminator to be hashed so that the source file name is omitted and not 
> ABI. Not that I think it'd be elegant, but it would not be abusable like 
> _silgen_name.

That wouldn’t solve the problem where removing @_versioned(name) and adding 
public would change the symbol’s name.

However, your idea of mangling versioned private symbols like internal and 
diagnosing conflicts might be workable.

Slava

> 
>> 
>> A more elegant refinement could be to have @_versioned private and 
>> fileprivate members mangled as though internal, erroring if two or more 
>> members with the same name are both @_versioned--would that work?
>> 
> 
> If you’re going to do that what is the value in having the capability at all?
> 
> Solely to have some way of preventing members in one file from calling 
> members in another file at compile time.

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

2017-10-02 Thread Chris Lattner via swift-evolution

On Oct 2, 2017, at 3:24 PM, Xiaodi Wu  wrote:
>> Especially if people want to use the character in question as both an 
>> identifier and an operator: We can make the character an identifier and its 
>> lookalike an operator (or the other way around).
> 
> Off the top of my head...
> In calculus, “𝖽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine substitute 
> for "d" in “𝖽y/𝖽x” ("the derivative of y(x) with respect to x").
> In statistics, we could use "𝖢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in 
> "5𝖢3" to mimic the "5C3" notation ("5 choose 3"). And although not strictly 
> an issue of identifiers vs operators, “！” (FULLWIDTH EXCLAMATION MARK) would 
> be an ok substitution (that extra space on the right looks funny) for "!" in 
> “4！” ("4 factorial").
> 
> I'm sure there are other examples from math/science/ "symbology"-heavy DSL here>, but “d” in particular is one that I’ve wanted 
> for a while since Swift classifies "∂" (the partial derivative operator) as 
> an operator rather than an identifier, making it impossible to use a 
> consistent syntax between normal derivatives and partial derivatives (normal 
> derivatives are "d(y)/d(x)", whereas partial derivatives get to drop the 
> parens "∂y/∂x")
> 
> Allowing a custom operator that looks like `!` to be anything other than the 
> force-unwrap operator would be unwise, IMO, and not a desirable goal. 
> Likewise characters that look like `d` not being the character `d`, etc. In 
> the previous PR, the authors deliberately created a system where these will 
> not be possible.

I completely agree with Xiaodi here.  Even if this were technically possible by 
the rules that are defined, it would still be very poor form to do this.  It 
would violate the swift goal of clarity of code.  If these operations need to 
be an operator, it would be better to define a *new* operator for these 
operations, so that a human at least knows that they don’t know what the 
operation does - rather than being misled into thinking they are a familiar 
construct.

> I think we should specify from the outset of re-examining this topic that 
> supporting arbitrary math/science notation without demonstrable improvement 
> in code clarity for actual, Swift code is a non-goal. Since manipulating 
> matrices is a common programming task, and the current BLAS syntax is 
> terribly cumbersome, being able to use operators for matrix multiplication, 
> inversion, etc. is imminently reasonable. Having a way of writing 
> `4.factorial()` that looks like an equation in a math textbook, however, 
> wouldn't pass that bar.

+100.  Clarity is the important thing, and sometimes operators are the right 
way to get that.  Emulating math syntax exactly is a non-goal.

-Chris

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

2017-10-02 Thread Chris Lattner via swift-evolution

> On Oct 2, 2017, at 1:13 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> If you tried hard enough, you could probably create a variable that looks 
> like it's shadowing one from an outer scope while it actually isn't, and use 
> the two to confuse readers. This could trick people into thinking that some 
> dangerous/backdoor code is actually good and safe, especially in the 
> open-source world where you can't always trust your contributors.
> 
> On one hand, other than the complexity of telling if two characters are 
> lookalikes, I don't know why Αrray (GREEK CAPITAL LETTER ALPHA) and Array 
> (LATIN CAPITAL LETTER A) should be considered different identifiers. On the 
> other hand, I struggle to imagine the specifics of an exploit that uses that. 
> You'd have to work pretty hard to assemble all the pieces of a backdoor in 
> visually-similar variable names without arousing suspicion.

I don’t think this is something we have to try hard to avoid.  It is true that 
some characters look similar, particularly in some fonts, but this isn’t new:

   let a1 = 42
   let al = 12
   let b = al + a1 

If there were real code that was maliciously shadowing to try to cause 
confusion, then you have a more serious problem on your hands than someone 
accidentally misunderstanding which one to use.

All I’m saying is that we shouldn’t complicate the design to solve this problem 
(IMO).  If it falls out of the solution somehow (e.g. just disallow invisible 
characters) then that’s great of course!

-Chris

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Mon, Oct 2, 2017 at 23:11 David Sweeris  wrote:

> On Oct 2, 2017, at 7:57 PM, Xiaodi Wu  wrote:
>
> On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris  wrote:
>
>>
>> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I’m all for fixing pressing issues requested by Xiaodi, but beyond that
>>> I request we give a little more thought to the long term direction.
>>>
>>> My 2¢ is I’ve been convinced that very few characters are “obviously”
>>> either a operator or identifier across all contexts where they might be
>>> used.  Thus relegating the vast majority of thousands of ambiguous
>>> characters to committee to decide a single global usage.  But that is both
>>> a huge time sink and fundamentally flawed in approach due to the contextual
>>> dependency of who is using them.
>>>
>>> For example, if a developer finds a set of symbols which perfectly
>>> denote some niche concept, do you really expect the developer to submit a
>>> proposal and wait months/years to get the characters classified and then a
>>> new compiler version to be distributed, all so that developer can adopt
>>> his/her own notation?
>>>
>>
>> The Unicode Consortium already has a document describing which Unicode
>> characters are suitable identifiers in programming languages, with guidance
>> as to how to customize that list around the edges. This is already adopted
>> by other programming languages. So, with little design effort, that task is
>> not only doable but largely done.
>>
>> As to operators, again, I am of the strong opinion that making it
>> possible for developers to adopt any preferred notation for any purpose (a)
>> is fundamentally incompatible with the division between operators and
>> identifiers, as I believe you’re saying here; and (b) should be a non-goal
>> from the outset. The only task, so far as I can tell, left to do is to
>> identify what pragmatic set of (mostly mathematical) symbols are used as
>> operators in the wider world and are likely to be already used in Swift
>> code or part of common use cases where an operator is clearly superior to
>> alternative spellings. In my view, the set of valid operator characters not
>> only shouldn’t require parsing or import directives, but should be small
>> enough to be knowable by memory.
>>
>>
>> The set notation operators should be identifiers, then?
>>
>
> Set notation operators aren't valid identifier characters; to be clear,
> the alternative to being a valid operator character would be simply not
> listing that character among valid operator or identifier characters.
>
>
>> Because the impression I got from the Set Algebra proposal a few months
>> ago is that there are a lot of people who’ve never even seen those
>> operators, let alone memorized them.
>>
>
> That's not the impression I got; the argument was that these symbols are
> hard to type and _not more recognizable that the English text_, which is
> certainly a plausible argument and the appropriate bar for deciding on a
> standard library API name.
>
> MHO is that the bar for a potentially valid operator character _for
> potential use in third-party APIs_ needn't be so high that we demand the
> character to be more recognizable to most people than alternative
> notations. Instead, we can probably justify including a character if it is
> (a) plausibly useful for some relatively common Swift use case and (b) at
> least somewhat recognizable for many people. Since set algebra has a
> well-accepted mathematical notation that's taught (afaict) at the _high
> school_ level if not earlier, and since set algebra functions are a part of
> the standard library, that surely meets those bars of usefulness and
> recognizability.
>
> Maybe they've started teaching it earlier than when I went through
> school... I don't think I learned it until Discrete Math, which IIRC was a
> 2nd or 3rd year course at my college and only required for Math, CS, and
> maybe EE majors. Anyway, WRT a), if Swift achieves its "take over the
> world" goal, *all* use cases will be Swift use cases. WRT b), "many" as
> in the numerical quantity or "many" as in the percentage? There are
> probably millions of people who recognize calculus's operators, but there
> are 7.5 *billion* people in the world.
>
> Keep in mind that Swift already goes far above and beyond in terms of
> operators
>
> Yep, that's is a large part of why I'm such a Swift fan :-D
>
> in that: (a) it allows overloading of almost all standard operators; (b)
> it permits the definition of effectively an infinite number of custom
> operators using characters found in standard operators; (c) it permits the
> definition of custom precedences for custom operators; and (d) it
> additionally permits the use of a wide number of Unicode characters for
> custom operators. Most systems programming languages don't even allow (a

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Mon, Oct 2, 2017 at 22:23 Slava Pestov  wrote:

> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu  wrote:
>
> On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov  wrote:
>
>>
>> On Oct 2, 2017, at 7:52 PM, Kelvin Ma  wrote:
>>
>> Is this only a problem with fileprivate or does it extend to private
>> members too? I feel like this would be a very valuable feature to support.
>>
>>
>> Private members too. Consider this example,
>>
>> struct S {
>>   private func f() {}
>> }
>>
>> The member S.f mangles
>> as _T06struct1SV1f33_AB643CAAAE0894CD0BC8584D7CA3AD23LLyyF. In this case, I
>> suppose we won’t need the private discriminator because there can only be
>> one S.f that’s directly a member of S, and not an extension. However
>> imagine if two different source files both defined extensions of S, with a
>> private member f. You would need to disambiguate them somehow.
>>
>
> The simple-minded way to do this would be to require @_versioned
> annotations on private and fileprivate members to supply an internally
> unique alternative name to be used for mangling-as-though-internal (i.e.
> `@_versioned(my_extension_f)`). Such a function becoming public in an
> ABI-compatible way would require renaming the "actual" name to the unique
> @_versioned name.
>
>
> We have _silgen_name for that, but we really don’t want to expose this
> more generally because people have been abusing it to make things visible
> to C, and they should be using @_cdecl instead.
>

The difference here would be that the "@_versioned name" would be subject
to mangling. It's essentially equivalent to a way of specifying a custom
discriminator to be hashed so that the source file name is omitted and not
ABI. Not that I think it'd be elegant, but it would not be abusable like
_silgen_name.


> A more elegant refinement could be to have @_versioned private and
> fileprivate members mangled as though internal, erroring if two or more
> members with the same name are both @_versioned--would that work?
>
>
> If you’re going to do that what is the value in having the capability at
> all?
>

Solely to have some way of preventing members in one file from calling
members in another file at compile time.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

2017-10-02 Thread David Sweeris via swift-evolution


> On Oct 2, 2017, at 7:57 PM, Xiaodi Wu  wrote:
> 
> On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris  > wrote:
> 
> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I 
>> request we give a little more thought to the long term direction.
>> 
>> My 2¢ is I’ve been convinced that very few characters are “obviously” either 
>> a operator or identifier across all contexts where they might be used.  Thus 
>> relegating the vast majority of thousands of ambiguous characters to 
>> committee to decide a single global usage.  But that is both a huge time 
>> sink and fundamentally flawed in approach due to the contextual dependency 
>> of who is using them.
>> 
>> For example, if a developer finds a set of symbols which perfectly denote 
>> some niche concept, do you really expect the developer to submit a proposal 
>> and wait months/years to get the characters classified and then a new 
>> compiler version to be distributed, all so that developer can adopt his/her 
>> own notation?
>> 
>> The Unicode Consortium already has a document describing which Unicode 
>> characters are suitable identifiers in programming languages, with guidance 
>> as to how to customize that list around the edges. This is already adopted 
>> by other programming languages. So, with little design effort, that task is 
>> not only doable but largely done.
>> 
>> As to operators, again, I am of the strong opinion that making it possible 
>> for developers to adopt any preferred notation for any purpose (a) is 
>> fundamentally incompatible with the division between operators and 
>> identifiers, as I believe you’re saying here; and (b) should be a non-goal 
>> from the outset. The only task, so far as I can tell, left to do is to 
>> identify what pragmatic set of (mostly mathematical) symbols are used as 
>> operators in the wider world and are likely to be already used in Swift code 
>> or part of common use cases where an operator is clearly superior to 
>> alternative spellings. In my view, the set of valid operator characters not 
>> only shouldn’t require parsing or import directives, but should be small 
>> enough to be knowable by memory.
> 
> The set notation operators should be identifiers, then?
> 
> Set notation operators aren't valid identifier characters; to be clear, the 
> alternative to being a valid operator character would be simply not listing 
> that character among valid operator or identifier characters.
>  
> Because the impression I got from the Set Algebra proposal a few months ago 
> is that there are a lot of people who’ve never even seen those operators, let 
> alone memorized them.
> 
> That's not the impression I got; the argument was that these symbols are hard 
> to type and _not more recognizable that the English text_, which is certainly 
> a plausible argument and the appropriate bar for deciding on a standard 
> library API name.
> 
> MHO is that the bar for a potentially valid operator character _for potential 
> use in third-party APIs_ needn't be so high that we demand the character to 
> be more recognizable to most people than alternative notations. Instead, we 
> can probably justify including a character if it is (a) plausibly useful for 
> some relatively common Swift use case and (b) at least somewhat recognizable 
> for many people. Since set algebra has a well-accepted mathematical notation 
> that's taught (afaict) at the _high school_ level if not earlier, and since 
> set algebra functions are a part of the standard library, that surely meets 
> those bars of usefulness and recognizability.
Maybe they've started teaching it earlier than when I went through school... I 
don't think I learned it until Discrete Math, which IIRC was a 2nd or 3rd year 
course at my college and only required for Math, CS, and maybe EE majors. 
Anyway, WRT a), if Swift achieves its "take over the world" goal, all use cases 
will be Swift use cases. WRT b), "many" as in the numerical quantity or "many" 
as in the percentage? There are probably millions of people who recognize 
calculus's operators, but there are 7.5 billion people in the world.

> Keep in mind that Swift already goes far above and beyond in terms of 
> operators
Yep, that's is a large part of why I'm such a Swift fan :-D

> in that: (a) it allows overloading of almost all standard operators; (b) it 
> permits the definition of effectively an infinite number of custom operators 
> using characters found in standard operators; (c) it permits the definition 
> of custom precedences for custom operators; and (d) it additionally permits 
> the use of a wide number of Unicode characters for custom operators. Most 
> systems programming languages don't even allow (a), let alone (b)

Re: [swift-evolution] Pitch: Cross-module inlining and specialization


> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu  wrote:
> 
> On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov  > wrote:
> 
>> On Oct 2, 2017, at 7:52 PM, Kelvin Ma > > wrote:
>> 
>> Is this only a problem with fileprivate or does it extend to private members 
>> too? I feel like this would be a very valuable feature to support.
> 
> Private members too. Consider this example,
> 
> struct S {
>   private func f() {}
> }
> 
> The member S.f mangles as 
> _T06struct1SV1f33_AB643CAAAE0894CD0BC8584D7CA3AD23LLyyF. In this case, I 
> suppose we won’t need the private discriminator because there can only be one 
> S.f that’s directly a member of S, and not an extension. However imagine if 
> two different source files both defined extensions of S, with a private 
> member f. You would need to disambiguate them somehow.
> 
> The simple-minded way to do this would be to require @_versioned annotations 
> on private and fileprivate members to supply an internally unique alternative 
> name to be used for mangling-as-though-internal (i.e. 
> `@_versioned(my_extension_f)`). Such a function becoming public in an 
> ABI-compatible way would require renaming the "actual" name to the unique 
> @_versioned name.

We have _silgen_name for that, but we really don’t want to expose this more 
generally because people have been abusing it to make things visible to C, and 
they should be using @_cdecl instead.

> 
> A more elegant refinement could be to have @_versioned private and 
> fileprivate members mangled as though internal, erroring if two or more 
> members with the same name are both @_versioned--would that work?
> 

If you’re going to do that what is the value in having the capability at all?

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On 01.10.2017 1:18, Chris Lattner wrote:
>
> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Vladimir, I agree with you on that change, but it’s a separate topic from
> this one.
>
> Tony is absolutely correct that this topic has already been discussed. It
> is a deliberate design decision that public types do not automatically
> expose members without explicit access modifiers; this has been brought up
> on this list, and it is clearly not in scope for discussion as no new
> insight can arise this late in the game. The inconsistency with public
> extensions was brought up, the proposed solution was to remove modifiers
> for extensions, but this proposal was rejected. So, the final design is
> what we have.
>
> Agreed.  The core team would only consider a refinement or change to
> access control if there were something actively broken that mattered for
> ABI stability.
>
>
> So we have to live with *protected* extension inconsistency for very long
> time just because core team don't want to even discuss _this particular_
> inconsistency(when access level in *private extension* must be private, not
> fileprivate)?
>
> Yes, we decided that access level for extension will mean a default and
> top most access level for nested methods, OK. But even in this rule, which
> already differ from access modifiers for types, we have another one special
> case for 'private extension'.
>
> Don't you think this is not normal situation and actually there IMO can't
> be any reason to keep this bug-producing inconsistency in Swift?
> (especially given Swift 5 seems like is a last moment to fix this)
>
>
> I hate to say it but I'm inclined to agree with Vladimir on this. "private
> extension" has a useful meaning now distinct from "fileprivate extension",
> and it was an oversight that SE-0169
> 
>  didn't
> include a fix here. On this *very narrow, very specific *access control
> issue I think it would still be worth discussing; like Xiaodi said it's not
> related to James' original thread-starter.
>
>
> I agree with this in principle but would not want to see it become a
> slippery slope back into extremely long access control discussions.
>
>
As I've said elsewhere, I too agree with this in principle. I agree with
Jordan that the current state of things is justifiable but the alternative
would be somewhat superior, agree that in a vacuum this very narrow and
specific discussion might be warranted, and agree also that this could be a
very slippery slide down a very steep slope.


> (I maintain that the current model does *not* include a special case; it
> simply means the 'private' is resolved at the level of the extension rather
> than the level of its members. But that isn't what people expect and it's
> not as useful.)
>
>
> I agree that changing the behavior of *all* access modifiers on
> extensions is out of scope. (I also agree that it is a bad idea. Sorry,
> James, but wanting 'pubic' here indicates that your mental model of
> extensions does not match what Swift is actually doing, and that could get
> you into trouble.)
>
> Jordan
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov  wrote:

>
> On Oct 2, 2017, at 7:52 PM, Kelvin Ma  wrote:
>
> Is this only a problem with fileprivate or does it extend to private
> members too? I feel like this would be a very valuable feature to support.
>
>
> Private members too. Consider this example,
>
> struct S {
>   private func f() {}
> }
>
> The member S.f mangles as 
> _T06struct1SV1f33_AB643CAAAE0894CD0BC8584D7CA3AD23LLyyF.
> In this case, I suppose we won’t need the private discriminator because
> there can only be one S.f that’s directly a member of S, and not an
> extension. However imagine if two different source files both defined
> extensions of S, with a private member f. You would need to disambiguate
> them somehow.
>

The simple-minded way to do this would be to require @_versioned
annotations on private and fileprivate members to supply an internally
unique alternative name to be used for mangling-as-though-internal (i.e.
`@_versioned(my_extension_f)`). Such a function becoming public in an
ABI-compatible way would require renaming the "actual" name to the unique
@_versioned name.

A more elegant refinement could be to have @_versioned private and
fileprivate members mangled as though internal, erroring if two or more
members with the same name are both @_versioned--would that work?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Mon, Oct 2, 2017 at 9:04 PM, David Sweeris  wrote:

>
> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I
>> request we give a little more thought to the long term direction.
>>
>> My 2¢ is I’ve been convinced that very few characters are “obviously”
>> either a operator or identifier across all contexts where they might be
>> used.  Thus relegating the vast majority of thousands of ambiguous
>> characters to committee to decide a single global usage.  But that is both
>> a huge time sink and fundamentally flawed in approach due to the contextual
>> dependency of who is using them.
>>
>> For example, if a developer finds a set of symbols which perfectly denote
>> some niche concept, do you really expect the developer to submit a proposal
>> and wait months/years to get the characters classified and then a new
>> compiler version to be distributed, all so that developer can adopt his/her
>> own notation?
>>
>
> The Unicode Consortium already has a document describing which Unicode
> characters are suitable identifiers in programming languages, with guidance
> as to how to customize that list around the edges. This is already adopted
> by other programming languages. So, with little design effort, that task is
> not only doable but largely done.
>
> As to operators, again, I am of the strong opinion that making it possible
> for developers to adopt any preferred notation for any purpose (a) is
> fundamentally incompatible with the division between operators and
> identifiers, as I believe you’re saying here; and (b) should be a non-goal
> from the outset. The only task, so far as I can tell, left to do is to
> identify what pragmatic set of (mostly mathematical) symbols are used as
> operators in the wider world and are likely to be already used in Swift
> code or part of common use cases where an operator is clearly superior to
> alternative spellings. In my view, the set of valid operator characters not
> only shouldn’t require parsing or import directives, but should be small
> enough to be knowable by memory.
>
>
> The set notation operators should be identifiers, then?
>

Set notation operators aren't valid identifier characters; to be clear, the
alternative to being a valid operator character would be simply not listing
that character among valid operator or identifier characters.

> Because the impression I got from the Set Algebra proposal a few months
> ago is that there are a lot of people who’ve never even seen those
> operators, let alone memorized them.
>

That's not the impression I got; the argument was that these symbols are
hard to type and _not more recognizable that the English text_, which is
certainly a plausible argument and the appropriate bar for deciding on a
standard library API name.

MHO is that the bar for a potentially valid operator character _for
potential use in third-party APIs_ needn't be so high that we demand the
character to be more recognizable to most people than alternative
notations. Instead, we can probably justify including a character if it is
(a) plausibly useful for some relatively common Swift use case and (b) at
least somewhat recognizable for many people. Since set algebra has a
well-accepted mathematical notation that's taught (afaict) at the _high
school_ level if not earlier, and since set algebra functions are a part of
the standard library, that surely meets those bars of usefulness and
recognizability.

Keep in mind that Swift already goes far above and beyond in terms of
operators, in that: (a) it allows overloading of almost all standard
operators; (b) it permits the definition of effectively an infinite number
of custom operators using characters found in standard operators; (c) it
permits the definition of custom precedences for custom operators; and (d)
it additionally permits the use of a wide number of Unicode characters for
custom operators. Most systems programming languages don't even allow (a),
let alone (b) or (c). Even dramatically curtailing (d) leaves Swift with an
unusually expansive support for custom operators. What it does conclusively
foreclose is something which ought to be stated firmly as a non-goal, which
is the typesetting of arbitrary mathematical equations as valid Swift code.
Quite simply, Swift is not math; simple addition doesn't even behave as it
does in grade-school arithmetic, so there is no sense in attempting to
shoehorn calculus into the language.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Cross-module inlining and specialization


> On Oct 2, 2017, at 7:52 PM, Kelvin Ma  wrote:
> 
> Is this only a problem with fileprivate or does it extend to private members 
> too? I feel like this would be a very valuable feature to support.

Private members too. Consider this example,

struct S {
  private func f() {}
}

The member S.f mangles as 
_T06struct1SV1f33_AB643CAAAE0894CD0BC8584D7CA3AD23LLyyF. In this case, I 
suppose we won’t need the private discriminator because there can only be one 
S.f that’s directly a member of S, and not an extension. However imagine if two 
different source files both defined extensions of S, with a private member f. 
You would need to disambiguate them somehow.

Slava

> 
> On Mon, Oct 2, 2017 at 9:43 PM, Slava Pestov  > wrote:
> It would be a trivial change to allow @_versioned on private and fileprivate 
> declarations, but there are two pitfalls to keep in mind:
> 
> - Private symbols are mangled with a ‘discriminator’ which is basically a 
> hash of the file name. So now it would be part of the ABI, which seems 
> fragile — you can’t move the private function to another source file, or 
> rename the source file.
> 
> - Similarly, right now a @_versioned function becoming public is an ABI 
> compatible change. This would no longer work if you could have private 
> @_versioned functions, because the symbol name would change if it became 
> public.
> 
> For these reasons we decided against “private versioned” as a concept. I feel 
> like internal is enough here.
> 
> Slava
>  
>> On Oct 2, 2017, at 4:54 PM, Taylor Swift > > wrote:
>> 
>> Right now @_versioned is only for internal declarations. We should have 
>> something similar for private and fileprivate declarations. I think most 
>> people use those modifiers for code organization, not binary resilience, so 
>> we would do well to make the two intents separate and explicit.
>> 
>> On Mon, Oct 2, 2017 at 6:42 PM, Xiaodi Wu > > wrote:
>> 
>> On Mon, Oct 2, 2017 at 17:41 Taylor Swift > > wrote:
>> I think we should try to separate visibility from access control. In other 
>> words, the compiler should be able to see more than the user. I want to be 
>> able to write private and internal code that cannot be called explicitly in 
>> source, but can still be inlined by the compiler. Right now people are doing 
>> this with underscored methods and variable names but I don’t think that’s a 
>> good convention to use. We should have something at the language level that 
>> enforces that something shouldn’t be referenced by name outside of its 
>> scope, but is public for all compilation and ABI purposes. Maybe an 
>> attribute like @visible or a new keyword or something.
>> 
>> Right, that’s @_versioned, essentially.
>> 
>> 
>> On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> This is unduly restrictive; @_versioned (despite being the wrong spelling) 
>> is what we want here. To be callable from an inlinable function, internal 
>> things need only be visible in terms of public ABI, not necessarily 
>> inlinable, just as public things need only be public and not necessarily 
>> inlinable.
>> On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov > > wrote:
>> Thanks for taking a look!
>> 
>> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky 
>> > > > > wrote:
>> > 3. Even though @inlinable will have no effect on declarations which are 
>> > not public, we should still allow it to be placed there. That way when the 
>> > access level is later changed to be public, the attribute is already where 
>> > it should be. This is similar to why we permit, eg., members of an 
>> > internal type to be declared public, which was discussed and decided 
>> > previously on Swift Evolution.
>> 
>> This is an interesting point. Do you think the attribute should be 
>> completely ignored, or should the restrictions on references to non-public 
>> things, etc still be enforced?
>> 
>>  Hmm, good question!
>> 
>> I rather like the idea Greg Parker put forth, where non-public @inlinable 
>> items can be used by public @inlinable ones, which implies that the 
>> restrictions should indeed still apply—something @inlinable can only 
>> reference public or @inlinable things.
>> 
>> Nevin
>> ___
>> 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/li

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

2017-10-02 Thread Kelvin Ma via swift-evolution

Is this only a problem with fileprivate or does it extend to private
members too? I feel like this would be a very valuable feature to support.

On Mon, Oct 2, 2017 at 9:43 PM, Slava Pestov  wrote:

> It would be a trivial change to allow @_versioned on private and
> fileprivate declarations, but there are two pitfalls to keep in mind:
>
> - Private symbols are mangled with a ‘discriminator’ which is basically a
> hash of the file name. So now it would be part of the ABI, which seems
> fragile — you can’t move the private function to another source file, or
> rename the source file.
>
> - Similarly, right now a @_versioned function becoming public is an ABI
> compatible change. This would no longer work if you could have private
> @_versioned functions, because the symbol name would change if it became
> public.
>
> For these reasons we decided against “private versioned” as a concept. I
> feel like internal is enough here.
>
> Slava
>
>
> On Oct 2, 2017, at 4:54 PM, Taylor Swift  wrote:
>
> Right now @_versioned is only for internal declarations. We should have
> something similar for private and fileprivate declarations. I think most
> people use those modifiers for code organization, not binary resilience, so
> we would do well to make the two intents separate and explicit.
>
> On Mon, Oct 2, 2017 at 6:42 PM, Xiaodi Wu  wrote:
>
>>
>> On Mon, Oct 2, 2017 at 17:41 Taylor Swift  wrote:
>>
>>> I think we should try to separate visibility from access control. In
>>> other words, the compiler should be able to see more than the user. I want
>>> to be able to write private and internal code that cannot be called
>>> explicitly in source, but can still be inlined by the compiler. Right now
>>> people are doing this with underscored methods and variable names but I
>>> don’t think that’s a good convention to use. We should have something at
>>> the language level that enforces that something shouldn’t be referenced by
>>> name outside of its scope, but is public for all compilation and ABI
>>> purposes. Maybe an attribute like @visible or a new keyword or something.
>>>
>>
>> Right, that’s @_versioned, essentially.
>>
>>
>> On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 This is unduly restrictive; @_versioned (despite being the wrong
 spelling) is what we want here. To be callable from an inlinable function,
 internal things need only be visible in terms of public ABI, not
 necessarily inlinable, just as public things need only be public and not
 necessarily inlinable.
 On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via
 swift-evolution  wrote:

> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov 
> wrote:
>
>> Thanks for taking a look!
>>
>> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <
>> nevin.brackettrozin...@gmail.com> wrote:
>> > 3. Even though @inlinable will have no effect on declarations which
>> are not public, we should still allow it to be placed there. That way 
>> when
>> the access level is later changed to be public, the attribute is already
>> where it should be. This is similar to why we permit, eg., members of an
>> internal type to be declared public, which was discussed and decided
>> previously on Swift Evolution.
>>
>> This is an interesting point. Do you think the attribute should be
>> completely ignored, or should the restrictions on references to 
>> non-public
>> things, etc still be enforced?
>>
>
>  Hmm, good question!
>
> I rather like the idea Greg Parker put forth, where non-public
> @inlinable items can be used by public @inlinable ones, which implies that
> the restrictions should indeed still apply—something @inlinable can only
> reference public or @inlinable things.
>
> Nevin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

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


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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

It would be a trivial change to allow @_versioned on private and fileprivate 
declarations, but there are two pitfalls to keep in mind:

- Private symbols are mangled with a ‘discriminator’ which is basically a hash 
of the file name. So now it would be part of the ABI, which seems fragile — you 
can’t move the private function to another source file, or rename the source 
file.

- Similarly, right now a @_versioned function becoming public is an ABI 
compatible change. This would no longer work if you could have private 
@_versioned functions, because the symbol name would change if it became public.

For these reasons we decided against “private versioned” as a concept. I feel 
like internal is enough here.

Slava
 
> On Oct 2, 2017, at 4:54 PM, Taylor Swift  wrote:
> 
> Right now @_versioned is only for internal declarations. We should have 
> something similar for private and fileprivate declarations. I think most 
> people use those modifiers for code organization, not binary resilience, so 
> we would do well to make the two intents separate and explicit.
> 
> On Mon, Oct 2, 2017 at 6:42 PM, Xiaodi Wu  > wrote:
> 
> On Mon, Oct 2, 2017 at 17:41 Taylor Swift  > wrote:
> I think we should try to separate visibility from access control. In other 
> words, the compiler should be able to see more than the user. I want to be 
> able to write private and internal code that cannot be called explicitly in 
> source, but can still be inlined by the compiler. Right now people are doing 
> this with underscored methods and variable names but I don’t think that’s a 
> good convention to use. We should have something at the language level that 
> enforces that something shouldn’t be referenced by name outside of its scope, 
> but is public for all compilation and ABI purposes. Maybe an attribute like 
> @visible or a new keyword or something.
> 
> Right, that’s @_versioned, essentially.
> 
> 
> On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> This is unduly restrictive; @_versioned (despite being the wrong spelling) is 
> what we want here. To be callable from an inlinable function, internal things 
> need only be visible in terms of public ABI, not necessarily inlinable, just 
> as public things need only be public and not necessarily inlinable.
> On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov  > wrote:
> Thanks for taking a look!
> 
> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky 
> >  > > wrote:
> > 3. Even though @inlinable will have no effect on declarations which are not 
> > public, we should still allow it to be placed there. That way when the 
> > access level is later changed to be public, the attribute is already where 
> > it should be. This is similar to why we permit, eg., members of an internal 
> > type to be declared public, which was discussed and decided previously on 
> > Swift Evolution.
> 
> This is an interesting point. Do you think the attribute should be completely 
> ignored, or should the restrictions on references to non-public things, etc 
> still be enforced?
> 
>  Hmm, good question!
> 
> I rather like the idea Greg Parker put forth, where non-public @inlinable 
> items can be used by public @inlinable ones, which implies that the 
> restrictions should indeed still apply—something @inlinable can only 
> reference public or @inlinable things.
> 
> Nevin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

2017-10-02 Thread Matthew Johnson via swift-evolution



Sent from my iPad

> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 
>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>>  wrote:
>> 
>> On 01.10.2017 1:18, Chris Lattner wrote:
 On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
  wrote:
 
 Vladimir, I agree with you on that change, but it’s a separate topic from 
 this one.
 
 Tony is absolutely correct that this topic has already been discussed. It 
 is a deliberate design decision that public types do not automatically 
 expose members without explicit access modifiers; this has been brought up 
 on this list, and it is clearly not in scope for discussion as no new 
 insight can arise this late in the game. The inconsistency with public 
 extensions was brought up, the proposed solution was to remove modifiers 
 for extensions, but this proposal was rejected. So, the final design is 
 what we have.
>>> Agreed.  The core team would only consider a refinement or change to access 
>>> control if there were something actively broken that mattered for ABI 
>>> stability.
>> 
>> So we have to live with *protected* extension inconsistency for very long 
>> time just because core team don't want to even discuss _this particular_ 
>> inconsistency(when access level in *private extension* must be private, not 
>> fileprivate)?
>> 
>> Yes, we decided that access level for extension will mean a default and top 
>> most access level for nested methods, OK. But even in this rule, which 
>> already differ from access modifiers for types, we have another one special 
>> case for 'private extension'.
>> 
>> Don't you think this is not normal situation and actually there IMO can't be 
>> any reason to keep this bug-producing inconsistency in Swift? (especially 
>> given Swift 5 seems like is a last moment to fix this)
> 
> I hate to say it but I'm inclined to agree with Vladimir on this. "private 
> extension" has a useful meaning now distinct from "fileprivate extension", 
> and it was an oversight that SE-0169 didn't include a fix here. On this very 
> narrow, very specific access control issue I think it would still be worth 
> discussing; like Xiaodi said it's not related to James' original 
> thread-starter.

I agree with this in principle but would not want to see it become a slippery 
slope back into extremely long access control discussions.

> 
> (I maintain that the current model does not include a special case; it simply 
> means the 'private' is resolved at the level of the extension rather than the 
> level of its members. But that isn't what people expect and it's not as 
> useful.)
> 
> 
> I agree that changing the behavior of all access modifiers on extensions is 
> out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 
> 'pubic' here indicates that your mental model of extensions does not match 
> what Swift is actually doing, and that could get you into trouble.)
> 
> Jordan
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

2017-10-02 Thread David Sweeris via swift-evolution


> On Oct 2, 2017, at 6:52 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Thanks for hoisting this out into its own thread, Jordan. I was hesitant to 
> elaborate more on another access level thread :)
> 
> I think the change should absolutely be made. Even though the "private" 
> keyword occurs at the file level, the description of the feature in the Swift 
> documentation simply states: "you can mark an extension with an explicit 
> access-level modifier to set a new default access level for all members 
> defined within the extension." To me, that implies that "private extension 
> Foo { func bar() }" should be identical to "extension Foo { private func 
> bar() }", but today it becomes equivalent to "extension Foo { fileprivate 
> func bar() }".
> 
> That seems fundamentally broken, because (1) it's inconsistent, (2) "private 
> extension" and "fileprivate extension" are two ways of saying the same thing, 
> non-intuitively, and (3) there's no way for someone to use the shorthand 
> syntax to take advantage of the new meaning of private within same-file type 
> extensions.
> 
> While I personally never use the shorthand extension access level feature 
> (because I prefer the explicit form, and because of situations like this 
> one), I definitely think it should be consistent for people who do want to 
> use it.
> 
> I wonder how much existing code would be affected by this change. Do people 
> use "private extension" when they really want "fileprivate extension"? I 
> would hope the number of users affected would be few, at least.

I don’t think I’ve ever used “private extension”, but if I did, I’d expect it 
to not mean “fileprivate extension”.

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

2017-10-02 Thread David Sweeris via swift-evolution


> On Oct 2, 2017, at 5:45 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution 
>>  wrote:
>> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I 
>> request we give a little more thought to the long term direction.
>> 
>> My 2¢ is I’ve been convinced that very few characters are “obviously” either 
>> a operator or identifier across all contexts where they might be used.  Thus 
>> relegating the vast majority of thousands of ambiguous characters to 
>> committee to decide a single global usage.  But that is both a huge time 
>> sink and fundamentally flawed in approach due to the contextual dependency 
>> of who is using them.
>> 
>> For example, if a developer finds a set of symbols which perfectly denote 
>> some niche concept, do you really expect the developer to submit a proposal 
>> and wait months/years to get the characters classified and then a new 
>> compiler version to be distributed, all so that developer can adopt his/her 
>> own notation?
> 
> The Unicode Consortium already has a document describing which Unicode 
> characters are suitable identifiers in programming languages, with guidance 
> as to how to customize that list around the edges. This is already adopted by 
> other programming languages. So, with little design effort, that task is not 
> only doable but largely done.
> 
> As to operators, again, I am of the strong opinion that making it possible 
> for developers to adopt any preferred notation for any purpose (a) is 
> fundamentally incompatible with the division between operators and 
> identifiers, as I believe you’re saying here; and (b) should be a non-goal 
> from the outset. The only task, so far as I can tell, left to do is to 
> identify what pragmatic set of (mostly mathematical) symbols are used as 
> operators in the wider world and are likely to be already used in Swift code 
> or part of common use cases where an operator is clearly superior to 
> alternative spellings. In my view, the set of valid operator characters not 
> only shouldn’t require parsing or import directives, but should be small 
> enough to be knowable by memory.

The set notation operators should be identifiers, then? Because the impression 
I got from the Set Algebra proposal a few months ago is that there are a lot of 
people who’ve never even seen those operators, let alone memorized them.

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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

2017-10-02 Thread David Sweeris via swift-evolution

> On Oct 2, 2017, at 3:24 PM, Xiaodi Wu  wrote:
> 
>> On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris  wrote:
>> 
>>> On Oct 2, 2017, at 09:14, Xiaodi Wu  wrote:
>>> 
>>> What is your use case for this?
>>> 
 On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution 
  wrote:

> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution 
>>  wrote:
>> 
>> Hi All.
>> 
>> I’d like to help as well. I have fun with operators.
>> 
>> There is also the issue of code security with invisible unicode 
>> characters and characters that look exactly alike.
> 
> Unless there is a compelling reason to add them, I think we should ban 
> invisible characters.  What is the harm of characters that look alike?

 Especially if people want to use the character in question as both an 
 identifier and an operator: We can make the character an identifier and 
 its lookalike an operator (or the other way around).
>> 
>> Off the top of my head...
>> In calculus, “𝖽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine 
>> substitute for "d" in “𝖽y/𝖽x” ("the derivative of y(x) with respect to x").
>> In statistics, we could use "𝖢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in 
>> "5𝖢3" to mimic the "5C3" notation ("5 choose 3"). And although not strictly 
>> an issue of identifiers vs operators, “！” (FULLWIDTH EXCLAMATION MARK) would 
>> be an ok substitution (that extra space on the right looks funny) for "!" in 
>> “4！” ("4 factorial").
>> 
>> I'm sure there are other examples from math/science/> "symbology"-heavy DSL here>, but “d” in particular is one that I’ve wanted 
>> for a while since Swift classifies "∂" (the partial derivative operator) as 
>> an operator rather than an identifier, making it impossible to use a 
>> consistent syntax between normal derivatives and partial derivatives (normal 
>> derivatives are "d(y)/d(x)", whereas partial derivatives get to drop the 
>> parens "∂y/∂x")
> 
> I think we should specify from the outset of re-examining this topic that 
> supporting arbitrary math/science notation without demonstrable improvement 
> in code clarity for actual, Swift code is a non-goal.

I gave up on trying to get the restrictions on the normal "!" removed a while 
ago... I guess we'll just have to agree to disagree on !-lookalikes.

Supporting arbitrary math/science notation, though, is almost by definition an 
increase in code clarity for the people who are used to it. Is that everyone? 
Of course not. Is it the majority? I doubt it; the days when Computer Science 
was part of the Math department are long gone, and it's common for people to 
become developers without getting any formal education in the field at all 
(which is great, IMHO... that means we're successfully making computing more 
accessible). That doesn't seem to me like a good reason not to support such 
symbolic notations, though. I'm not suggesting a change to the standard library 
here, to be forced on everyone -- I'm merely suggesting a way to help people 
who prefer the more symbol-heavy notations to use them if they and their teams 
(and their clients, if they're a library vendor) want to.

I would never claim that the particular cases I raised are “critical to Swift's 
long-term success” or anything (I think the # of people who care about "𝖽y" vs 
"d(y)" enough to let it dictate their language choice is probably zero), but I 
would like to point out that a few of the threads here have demonstrated just 
how differing the opinions are on this matter even within the relatively small 
group of people who participate on this list. If Swift’s long-term goal is to 
take over the world, that means the language needs to “work” for very diverse 
groups of people... We probably shouldn’t be restricting syntax at the language 
level unless we actually have to.

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

2017-10-02 Thread Tony Allevato via swift-evolution

Thanks for hoisting this out into its own thread, Jordan. I was hesitant to
elaborate more on another access level thread :)

I think the change should absolutely be made. Even though the "private"
keyword occurs at the file level, the description of the feature in the
Swift documentation simply states: "you can mark an extension with an
explicit access-level modifier to set a new default access level for all
members defined within the extension." To me, that implies that "private
extension Foo { func bar() }" should be identical to "extension Foo {
private func bar() }", but today it becomes equivalent to "extension Foo {
fileprivate func bar() }".

That seems fundamentally broken, because (1) it's inconsistent, (2)
"private extension" and "fileprivate extension" are two ways of saying the
same thing, non-intuitively, and (3) there's no way for someone to use the
shorthand syntax to take advantage of the new meaning of private within
same-file type extensions.

While I personally never use the shorthand extension access level feature
(because I prefer the explicit form, and because of situations like this
one), I definitely think it should be consistent for people who do want to
use it.

I wonder how much existing code would be affected by this change. Do people
use "private extension" when they really want "fileprivate extension"? I
would hope the number of users affected would be few, at least.

On Mon, Oct 2, 2017 at 6:10 PM Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Oct 2, 2017, at 18:06, Jose Cheyo Jimenez  wrote:
>
>
> On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On 01.10.2017 1:18, Chris Lattner wrote:
>
> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Vladimir, I agree with you on that change, but it’s a separate topic from
> this one.
>
> Tony is absolutely correct that this topic has already been discussed. It
> is a deliberate design decision that public types do not automatically
> expose members without explicit access modifiers; this has been brought up
> on this list, and it is clearly not in scope for discussion as no new
> insight can arise this late in the game. The inconsistency with public
> extensions was brought up, the proposed solution was to remove modifiers
> for extensions, but this proposal was rejected. So, the final design is
> what we have.
>
> Agreed.  The core team would only consider a refinement or change to
> access control if there were something actively broken that mattered for
> ABI stability.
>
>
> So we have to live with *protected* extension inconsistency for very long
> time just because core team don't want to even discuss _this particular_
> inconsistency(when access level in *private extension* must be private, not
> fileprivate)?
>
> Yes, we decided that access level for extension will mean a default and
> top most access level for nested methods, OK. But even in this rule, which
> already differ from access modifiers for types, we have another one special
> case for 'private extension'.
>
> Don't you think this is not normal situation and actually there IMO can't
> be any reason to keep this bug-producing inconsistency in Swift?
> (especially given Swift 5 seems like is a last moment to fix this)
>
>
> I hate to say it but I'm inclined to agree with Vladimir on this. "private
> extension" has a useful meaning now distinct from "fileprivate extension",
> and it was an oversight that SE-0169
> 
>  didn't
> include a fix here. On this *very narrow, very specific *access control
> issue I think it would still be worth discussing; like Xiaodi said it's not
> related to James' original thread-starter.
>
> (I maintain that the current model does *not* include a special case; it
> simply means the 'private' is resolved at the level of the extension rather
> than the level of its members. But that isn't what people expect and it's
> not as useful.)
>
>
> I agree that changing the behavior of *all* access modifiers on
> extensions is out of scope. (I also agree that it is a bad idea. Sorry,
> James, but wanting 'pubic' here indicates that your mental model of
> extensions does not match what Swift is actually doing, and that could get
> you into trouble.)
>
> Jordan
>
>
>
> I am not in favor of including a special case for “private extension”
> because like Jordan said, private is resolved at the level of the extension
> which is always top level currently. A change would make sense if we start
> allowing extensions that are not top level. Anything private that is top
> level is equivalent to fileprivate so why should “private extension” be any
> different?
>
>
> It's fair to be against t

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

2017-10-02 Thread Jose Cheyo Jimenez via swift-evolution



> On Oct 2, 2017, at 18:06, Jose Cheyo Jimenez  wrote:
> 
>> 
>> On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> On 01.10.2017 1:18, Chris Lattner wrote:
> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> Vladimir, I agree with you on that change, but it’s a separate topic from 
> this one.
> 
> Tony is absolutely correct that this topic has already been discussed. It 
> is a deliberate design decision that public types do not automatically 
> expose members without explicit access modifiers; this has been brought 
> up on this list, and it is clearly not in scope for discussion as no new 
> insight can arise this late in the game. The inconsistency with public 
> extensions was brought up, the proposed solution was to remove modifiers 
> for extensions, but this proposal was rejected. So, the final design is 
> what we have.
 Agreed.  The core team would only consider a refinement or change to 
 access control if there were something actively broken that mattered for 
 ABI stability.
>>> 
>>> So we have to live with *protected* extension inconsistency for very long 
>>> time just because core team don't want to even discuss _this particular_ 
>>> inconsistency(when access level in *private extension* must be private, not 
>>> fileprivate)?
>>> 
>>> Yes, we decided that access level for extension will mean a default and top 
>>> most access level for nested methods, OK. But even in this rule, which 
>>> already differ from access modifiers for types, we have another one special 
>>> case for 'private extension'.
>>> 
>>> Don't you think this is not normal situation and actually there IMO can't 
>>> be any reason to keep this bug-producing inconsistency in Swift? 
>>> (especially given Swift 5 seems like is a last moment to fix this)
>> 
>> I hate to say it but I'm inclined to agree with Vladimir on this. "private 
>> extension" has a useful meaning now distinct from "fileprivate extension", 
>> and it was an oversight that SE-0169 
>> 
>>  didn't include a fix here. On this very narrow, very specific access 
>> control issue I think it would still be worth discussing; like Xiaodi said 
>> it's not related to James' original thread-starter.
>> 
>> (I maintain that the current model does not include a special case; it 
>> simply means the 'private' is resolved at the level of the extension rather 
>> than the level of its members. But that isn't what people expect and it's 
>> not as useful.)
>> 
>> 
>> I agree that changing the behavior of all access modifiers on extensions is 
>> out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 
>> 'pubic' here indicates that your mental model of extensions does not match 
>> what Swift is actually doing, and that could get you into trouble.)
>> 
>> Jordan
> 
> 
> I am not in favor of including a special case for “private extension” because 
> like Jordan said, private is resolved at the level of the extension which is 
> always top level currently. A change would make sense if we start allowing 
> extensions that are not top level. Anything private that is top level is 
> equivalent to fileprivate so why should “private extension” be any different?

It's fair to be against this change, but I want to point out that neither of 
these are "special cases". Instead it's "access is resolved at the level of 
extension and then applied to the member" vs. "access is applied to the members 
and then resolved".

Jordan

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")


> On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 
>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> On 01.10.2017 1:18, Chris Lattner wrote:
 On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Vladimir, I agree with you on that change, but it’s a separate topic from 
 this one.
 
 Tony is absolutely correct that this topic has already been discussed. It 
 is a deliberate design decision that public types do not automatically 
 expose members without explicit access modifiers; this has been brought up 
 on this list, and it is clearly not in scope for discussion as no new 
 insight can arise this late in the game. The inconsistency with public 
 extensions was brought up, the proposed solution was to remove modifiers 
 for extensions, but this proposal was rejected. So, the final design is 
 what we have.
>>> Agreed.  The core team would only consider a refinement or change to access 
>>> control if there were something actively broken that mattered for ABI 
>>> stability.
>> 
>> So we have to live with *protected* extension inconsistency for very long 
>> time just because core team don't want to even discuss _this particular_ 
>> inconsistency(when access level in *private extension* must be private, not 
>> fileprivate)?
>> 
>> Yes, we decided that access level for extension will mean a default and top 
>> most access level for nested methods, OK. But even in this rule, which 
>> already differ from access modifiers for types, we have another one special 
>> case for 'private extension'.
>> 
>> Don't you think this is not normal situation and actually there IMO can't be 
>> any reason to keep this bug-producing inconsistency in Swift? (especially 
>> given Swift 5 seems like is a last moment to fix this)
> 
> I hate to say it but I'm inclined to agree with Vladimir on this. "private 
> extension" has a useful meaning now distinct from "fileprivate extension", 
> and it was an oversight that SE-0169 
> 
>  didn't include a fix here. On this very narrow, very specific access control 
> issue I think it would still be worth discussing; like Xiaodi said it's not 
> related to James' original thread-starter.
> 
> (I maintain that the current model does not include a special case; it simply 
> means the 'private' is resolved at the level of the extension rather than the 
> level of its members. But that isn't what people expect and it's not as 
> useful.)
> 
> 
> I agree that changing the behavior of all access modifiers on extensions is 
> out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 
> 'pubic' here indicates that your mental model of extensions does not match 
> what Swift is actually doing, and that could get you into trouble.)
> 
> Jordan


I am not in favor of including a special case for “private extension” because 
like Jordan said, private is resolved at the level of the extension which is 
always top level currently. A change would make sense if we start allowing 
extensions that are not top level. Anything private that is top level is 
equivalent to fileprivate so why should “private extension” be any different?

This is only confusing if people start mixing “fileprivate extension” and 
“private extension” in the same code base. 

We have a SwiftLint rule for this situation:
https://github.com/realm/SwiftLint/blame/master/Source/SwiftLintFramework/Rules/PrivateOverFilePrivateRule.swift
 


Alternatively you can enforce no extensions :)
https://github.com/realm/SwiftLint/blob/master/Source/SwiftLintFramework/Rules/NoExtensionAccessModifierRule.swift
 


“"There is no solution that will make everyone happy: maintaining the status 
quo makes “fileprivate” too common and therefore not meaningful when it occurs 
in source;”"
https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html
 











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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Sounds reasonable to me.


On Mon, Oct 2, 2017 at 18:54 Taylor Swift  wrote:

> Right now @_versioned is only for internal declarations. We should have
> something similar for private and fileprivate declarations. I think most
> people use those modifiers for code organization, not binary resilience, so
> we would do well to make the two intents separate and explicit.
>
> On Mon, Oct 2, 2017 at 6:42 PM, Xiaodi Wu  wrote:
>
>>
>> On Mon, Oct 2, 2017 at 17:41 Taylor Swift  wrote:
>>
>>> I think we should try to separate visibility from access control. In
>>> other words, the compiler should be able to see more than the user. I want
>>> to be able to write private and internal code that cannot be called
>>> explicitly in source, but can still be inlined by the compiler. Right now
>>> people are doing this with underscored methods and variable names but I
>>> don’t think that’s a good convention to use. We should have something at
>>> the language level that enforces that something shouldn’t be referenced by
>>> name outside of its scope, but is public for all compilation and ABI
>>> purposes. Maybe an attribute like @visible or a new keyword or something.
>>>
>>
>> Right, that’s @_versioned, essentially.
>>
>>
>> On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 This is unduly restrictive; @_versioned (despite being the wrong
 spelling) is what we want here. To be callable from an inlinable function,
 internal things need only be visible in terms of public ABI, not
 necessarily inlinable, just as public things need only be public and not
 necessarily inlinable.
 On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via
 swift-evolution  wrote:

> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov 
> wrote:
>
>> Thanks for taking a look!
>>
>> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <
>> nevin.brackettrozin...@gmail.com> wrote:
>> > 3. Even though @inlinable will have no effect on declarations which
>> are not public, we should still allow it to be placed there. That way 
>> when
>> the access level is later changed to be public, the attribute is already
>> where it should be. This is similar to why we permit, eg., members of an
>> internal type to be declared public, which was discussed and decided
>> previously on Swift Evolution.
>>
>> This is an interesting point. Do you think the attribute should be
>> completely ignored, or should the restrictions on references to 
>> non-public
>> things, etc still be enforced?
>>
>
>  Hmm, good question!
>
> I rather like the idea Greg Parker put forth, where non-public
> @inlinable items can be used by public @inlinable ones, which implies that
> the restrictions should indeed still apply—something @inlinable can only
> reference public or @inlinable things.
>
> Nevin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

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


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

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Mon, Oct 2, 2017 at 19:28 Ethan Tira-Thompson via swift-evolution <
swift-evolution@swift.org> wrote:

> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I
> request we give a little more thought to the long term direction.
>
> My 2¢ is I’ve been convinced that very few characters are “obviously”
> either a operator or identifier across all contexts where they might be
> used.  Thus relegating the vast majority of thousands of ambiguous
> characters to committee to decide a single global usage.  But that is both
> a huge time sink and fundamentally flawed in approach due to the contextual
> dependency of who is using them.
>
> For example, if a developer finds a set of symbols which perfectly denote
> some niche concept, do you really expect the developer to submit a proposal
> and wait months/years to get the characters classified and then a new
> compiler version to be distributed, all so that developer can adopt his/her
> own notation?
>

The Unicode Consortium already has a document describing which Unicode
characters are suitable identifiers in programming languages, with guidance
as to how to customize that list around the edges. This is already adopted
by other programming languages. So, with little design effort, that task is
not only doable but largely done.

As to operators, again, I am of the strong opinion that making it possible
for developers to adopt any preferred notation for any purpose (a) is
fundamentally incompatible with the division between operators and
identifiers, as I believe you’re saying here; and (b) should be a non-goal
from the outset. The only task, so far as I can tell, left to do is to
identify what pragmatic set of (mostly mathematical) symbols are used as
operators in the wider world and are likely to be already used in Swift
code or part of common use cases where an operator is clearly superior to
alternative spellings. In my view, the set of valid operator characters not
only shouldn’t require parsing or import directives, but should be small
enough to be knowable by memory.

And then after that is done, now say a member of some distant tribe
> complains they wanted to use one of those characters to write identifiers
> using their native language.  Even though there may be zero intersection
> between these two user groups, this path forces Swift itself to pick a side
> of one vs. the other.
>
> Surely there is some way to enable the local developer to resolve these
> choices rather than putting the swift language definition on the critical
> path?
>
> The goals I know of:
> 1. Performance: don’t require parsing all imports to get the operator set
> 2. Security: don’t let imports do surprising/obfuscated stuff
> 3. Functionality: do let users write what they want, or import/share
> libraries for niche domains
> 4. Well defined: resolve conflicts, e.g. between libraries
>
> I’m a little out of my league, but let’s say we want to use operator ᵀ
> from some matrixlib, how about:
> import matrixlib (operator: ᵀ)
>
> Or if you want several operators:
> import matrixlib (operators: [ᵀ,·,⊗])
>
> Ideally, any local operator definitions “just work” across their own
> module, but if it requires a “import (operator: ×)” in each file for
> performance, so be it.
>
> A whitelist of “standard” operators would automatically import (i.e.
> initialize the operator character list) to maintain compatibility with
> current usage.  But you can imagine additional arguments to the import
> call, such as “standardOperators: false” to import only the explicitly
> listed operators and reduce potential surprises.
>
> My rationale vs. the goals:
> 1. Performance: the operator character set vs. identifiers (everything
> else) can be determined within the file itself
> 2. Security: developer explicitly opts-in to the special operators they
> want to use, and readers can see where an operator comes from
> 3. Functionality: user is able to define their operators without getting
> committee involved
> 4. Well defined: potential conflict between libraries resolved by client’s
> choice to import or exclude the operator
>
> Does this have potential?
>
> -Ethan
>
> On Oct 2, 2017, at 10:59 AM, David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Oct 2, 2017, at 09:14, Xiaodi Wu  wrote:
>
> What is your use case for this?
>
> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi All.
>>
>> I’d like to help as well. I have fun with operators.
>>
>> There is also the issue of code security with invisible unicode
>> characters and characters that look exactly alike.
>>
>>
>> Unless there is a compelling reason to add them, I think we should ban
>> invisible characters.  What is the harm of c

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

2017-10-02 Thread Jon Gilbert via swift-evolution

Ethan-

This is brilliant. I don’t know if it’s technically feasible, but this is how 
it *should be.*

- Jonathan

> On Oct 2, 2017, at 17:28, Ethan Tira-Thompson via swift-evolution 
>  wrote:
> 
> I’m all for fixing pressing issues requested by Xiaodi, but beyond that I 
> request we give a little more thought to the long term direction.
> 
> My 2¢ is I’ve been convinced that very few characters are “obviously” either 
> a operator or identifier across all contexts where they might be used.  Thus 
> relegating the vast majority of thousands of ambiguous characters to 
> committee to decide a single global usage.  But that is both a huge time sink 
> and fundamentally flawed in approach due to the contextual dependency of who 
> is using them.
> 
> For example, if a developer finds a set of symbols which perfectly denote 
> some niche concept, do you really expect the developer to submit a proposal 
> and wait months/years to get the characters classified and then a new 
> compiler version to be distributed, all so that developer can adopt his/her 
> own notation?
> 
> And then after that is done, now say a member of some distant tribe complains 
> they wanted to use one of those characters to write identifiers using their 
> native language.  Even though there may be zero intersection between these 
> two user groups, this path forces Swift itself to pick a side of one vs. the 
> other.
> 
> Surely there is some way to enable the local developer to resolve these 
> choices rather than putting the swift language definition on the critical 
> path?
> 
> The goals I know of:
> 1. Performance: don’t require parsing all imports to get the operator set
> 2. Security: don’t let imports do surprising/obfuscated stuff
> 3. Functionality: do let users write what they want, or import/share 
> libraries for niche domains
> 4. Well defined: resolve conflicts, e.g. between libraries
> 
> I’m a little out of my league, but let’s say we want to use operator ᵀ from 
> some matrixlib, how about:
>   import matrixlib (operator: ᵀ)
> 
> Or if you want several operators:
>   import matrixlib (operators: [ᵀ,·,⊗])
> 
> Ideally, any local operator definitions “just work” across their own module, 
> but if it requires a “import (operator: ×)” in each file for performance, so 
> be it.
> 
> A whitelist of “standard” operators would automatically import (i.e. 
> initialize the operator character list) to maintain compatibility with 
> current usage.  But you can imagine additional arguments to the import call, 
> such as “standardOperators: false” to import only the explicitly listed 
> operators and reduce potential surprises.
> 
> My rationale vs. the goals:
> 1. Performance: the operator character set vs. identifiers (everything else) 
> can be determined within the file itself
> 2. Security: developer explicitly opts-in to the special operators they want 
> to use, and readers can see where an operator comes from
> 3. Functionality: user is able to define their operators without getting 
> committee involved
> 4. Well defined: potential conflict between libraries resolved by client’s 
> choice to import or exclude the operator
> 
> Does this have potential?
> 
> -Ethan
> 
> 
>> On Oct 2, 2017, at 10:59 AM, David Sweeris via swift-evolution 
>>  wrote:
>> 
>> 
>> On Oct 2, 2017, at 09:14, Xiaodi Wu  wrote:
>> 
>>> What is your use case for this?
>>> 
> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution 
>  wrote:
> 
>> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> 
>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution 
>>  wrote:
>> 
>> Hi All.
>> 
>> I’d like to help as well. I have fun with operators.
>> 
>> There is also the issue of code security with invisible unicode 
>> characters and characters that look exactly alike.
> 
> Unless there is a compelling reason to add them, I think we should ban 
> invisible characters.  What is the harm of characters that look alike?
 
 Especially if people want to use the character in question as both an 
 identifier and an operator: We can make the character an identifier and 
 its lookalike an operator (or the other way around).
>> 
>> Off the top of my head...
>> In calculus, “𝖽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine 
>> substitute for "d" in “𝖽y/𝖽x” ("the derivative of y(x) with respect to x").
>> In statistics, we could use "𝖢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in 
>> "5𝖢3" to mimic the "5C3" notation ("5 choose 3"). And although not strictly 
>> an issue of identifiers vs operators, “！” (FULLWIDTH EXCLAMATION MARK) would 
>> be an ok substitution (that extra space on the right looks funny) for "!" in 
>> “4！” ("4 factorial").
>> 
>> I'm sure there are other examples from math/science/> "symbology"-heavy DSL here>, but “d” in particular is one that I’ve wanted 
>> for a while since Swift classifies "∂" (the part

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

2017-10-02 Thread Ethan Tira-Thompson via swift-evolution

> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 01.10.2017 1:18, Chris Lattner wrote:
>>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> Vladimir, I agree with you on that change, but it’s a separate topic from 
>>> this one.
>>> 
>>> Tony is absolutely correct that this topic has already been discussed. It 
>>> is a deliberate design decision that public types do not automatically 
>>> expose members without explicit access modifiers; this has been brought up 
>>> on this list, and it is clearly not in scope for discussion as no new 
>>> insight can arise this late in the game. The inconsistency with public 
>>> extensions was brought up, the proposed solution was to remove modifiers 
>>> for extensions, but this proposal was rejected. So, the final design is 
>>> what we have.
>> Agreed.  The core team would only consider a refinement or change to access 
>> control if there were something actively broken that mattered for ABI 
>> stability.
> 
> So we have to live with *protected* extension inconsistency for very long 
> time just because core team don't want to even discuss _this particular_ 
> inconsistency(when access level in *private extension* must be private, not 
> fileprivate)?
> 
> Yes, we decided that access level for extension will mean a default and top 
> most access level for nested methods, OK. But even in this rule, which 
> already differ from access modifiers for types, we have another one special 
> case for 'private extension'.
> 
> Don't you think this is not normal situation and actually there IMO can't be 
> any reason to keep this bug-producing inconsistency in Swift? (especially 
> given Swift 5 seems like is a last moment to fix this)

I hate to say it but I'm inclined to agree with Vladimir on this. "private 
extension" has a useful meaning now distinct from "fileprivate extension", and 
it was an oversight that SE-0169 

 didn't include a fix here. On this very narrow, very specific access control 
issue I think it would still be worth discussing; like Xiaodi said it's not 
related to James' original thread-starter.

(I maintain that the current model does not include a special case; it simply 
means the 'private' is resolved at the level of the extension rather than the 
level of its members. But that isn't what people expect and it's not as useful.)

I agree that changing the behavior of all access modifiers on extensions is out 
of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 
'pubic' here indicates that your mental model of extensions does not match what 
Swift is actually doing, and that could get you into trouble.)

Jordan

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

Re: [swift-evolution] [Generics] [Pitch] Dependent Types

2017-10-02 Thread Félix Fischer via swift-evolution

Yes. At least, that’s a really good way to implement it.

On Mon, Oct 2, 2017 at 8:39 PM Taylor Swift  wrote:

> don’t we need something like this for Fixed Size Arrays™ too?
>
> On Mon, Oct 2, 2017 at 6:23 PM, Félix Fischer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi swift-evolution,
>>
>> I’ve been thinking for the past months of making math libraries that
>> could benefit from a dependent types system (see the Wikipedia article:
>> https://en.wikipedia.org/wiki/Dependent_type?wprov=sfti1). Dependent
>> types would allow for the type system to enforce certain correctness in
>> design that otherwise would have to be test-based. It would also discourage
>> type hacks that sort of implement it, but have poor semantics and clarity.
>>
>> Lemme give you an example:
>> - Let’s say you want to make a modulo arithmetic library. It has
>> applications in cryptography, but the fields existing there can also be
>> used for complete and *exact* linear algebra operations.
>> - Anyway. You want to make that. How?
>> - You’d want to have a struct that represented a number from a modulo
>> field.
>> - These numbers can be multiplied, added, have inverses, etc.
>> - But those operations only make sense if the prime P used for the modulo
>> operation is the same between them. Otherwise, what’s the point?
>> —> (Basically, you can’t just add (2 modulo 3) with (3 modulo 5). It
>> doesn’t make sense)
>> - You could do this in many different ways, and only a few (very hacky,
>> “static class in a where clause”-like) will actually enforce this condition
>> from the type system, which afaik is usually the best way to do so; both at
>> compile time and at run time.
>>
>> On the other hand, having dependent types allows you to have exactly this
>> kind of behavior:
>> - Now you can define a “dependent type”, for example ModuloInteger,
>> where P is the integer value that defines the type.
>> - Like this, you’ll have:
>> —> MI<2>: {0, 1}, where 1 + 1 = 0.
>> —> MI<3>: {0, 1, 2}, where 1 + 1 = 2, and 2 • 2 = 1
>> —> ... and so on.
>> - Such a type system can be used for even stronger type qualities (read
>> the Wikipedia article for good examples).
>> - Such strong type qualities are super nice for any critical systems and
>> for math libraries in general.
>> - And I guess for just general correctness and documentation. It gives
>> better semantics to our types.
>>
>> So, what do you say? Is this too crazy?
>>
>> Cheers,
>> Félix
>>
>> Btw if you know Haskell (which I don’t, but appreciate), you can check a
>> decent, Haskell-inspired, dependently typed language... here ~>
>> https://www.idris-lang.org/
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

I’m all for fixing pressing issues requested by Xiaodi, but beyond that I 
request we give a little more thought to the long term direction.

My 2¢ is I’ve been convinced that very few characters are “obviously” either a 
operator or identifier across all contexts where they might be used.  Thus 
relegating the vast majority of thousands of ambiguous characters to committee 
to decide a single global usage.  But that is both a huge time sink and 
fundamentally flawed in approach due to the contextual dependency of who is 
using them.

For example, if a developer finds a set of symbols which perfectly denote some 
niche concept, do you really expect the developer to submit a proposal and wait 
months/years to get the characters classified and then a new compiler version 
to be distributed, all so that developer can adopt his/her own notation?

And then after that is done, now say a member of some distant tribe complains 
they wanted to use one of those characters to write identifiers using their 
native language.  Even though there may be zero intersection between these two 
user groups, this path forces Swift itself to pick a side of one vs. the other.

Surely there is some way to enable the local developer to resolve these choices 
rather than putting the swift language definition on the critical path?

The goals I know of:
1. Performance: don’t require parsing all imports to get the operator set
2. Security: don’t let imports do surprising/obfuscated stuff
3. Functionality: do let users write what they want, or import/share libraries 
for niche domains
4. Well defined: resolve conflicts, e.g. between libraries

I’m a little out of my league, but let’s say we want to use operator ᵀ from 
some matrixlib, how about:
import matrixlib (operator: ᵀ)

Or if you want several operators:
import matrixlib (operators: [ᵀ,·,⊗])

Ideally, any local operator definitions “just work” across their own module, 
but if it requires a “import (operator: ×)” in each file for performance, so be 
it.

A whitelist of “standard” operators would automatically import (i.e. initialize 
the operator character list) to maintain compatibility with current usage.  But 
you can imagine additional arguments to the import call, such as 
“standardOperators: false” to import only the explicitly listed operators and 
reduce potential surprises.

My rationale vs. the goals:
1. Performance: the operator character set vs. identifiers (everything else) 
can be determined within the file itself
2. Security: developer explicitly opts-in to the special operators they want to 
use, and readers can see where an operator comes from
3. Functionality: user is able to define their operators without getting 
committee involved
4. Well defined: potential conflict between libraries resolved by client’s 
choice to import or exclude the operator

Does this have potential?

-Ethan

> On Oct 2, 2017, at 10:59 AM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
> On Oct 2, 2017, at 09:14, Xiaodi Wu  > wrote:
> 
>> What is your use case for this?
>> 
>> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
 On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:

 Hi All.

 I’d like to help as well. I have fun with operators.

 There is also the issue of code security with invisible unicode characters 
 and characters that look exactly alike.
>>> 
>>> Unless there is a compelling reason to add them, I think we should ban 
>>> invisible characters.  What is the harm of characters that look alike?
>> 
>> Especially if people want to use the character in question as both an 
>> identifier and an operator: We can make the character an identifier and its 
>> lookalike an operator (or the other way around).
> 
> Off the top of my head...
> In calculus, “𝖽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine substitute 
> for "d" in “𝖽y/𝖽x” ("the derivative of y(x) with respect to x").
> In statistics, we could use "𝖢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in 
> "5𝖢3" to mimic the "5C3" notation ("5 choose 3"). And although not strictly 
> an issue of identifiers vs operators, “！” (FULLWIDTH EXCLAMATION MARK) would 
> be an ok substitution (that extra space on the right looks funny) for "!" in 
> “4！” ("4 factorial").
> 
> I'm sure there are other examples from math/science/ "symbology"-heavy DSL here>, but “d” in particular is one that I’ve wanted 
> for a while since Swift classifies "∂" (the partial derivative operator) as 
> an operator rather than an identifier, making it impossible to use a 
> consistent syntax between normal derivatives and partial derivatives (normal 
> derivatives are "d(y)/d(x)", whereas partial derivatives get to drop the 
> parens "∂y/∂x

Re: [swift-evolution] [Generics] [Pitch] Dependent Types

2017-10-02 Thread Nevin Brackett-Rozinsky via swift-evolution

I rather suspect that we would be best served by starting with integer
literals as the only accepted “values in generics”. This would let us
define fixed-size arrays and matrices, the modular arithmetic types you
describe, and several other mathematical entities.

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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Right now @_versioned is only for internal declarations. We should have
something similar for private and fileprivate declarations. I think most
people use those modifiers for code organization, not binary resilience, so
we would do well to make the two intents separate and explicit.

On Mon, Oct 2, 2017 at 6:42 PM, Xiaodi Wu  wrote:

>
> On Mon, Oct 2, 2017 at 17:41 Taylor Swift  wrote:
>
>> I think we should try to separate visibility from access control. In
>> other words, the compiler should be able to see more than the user. I want
>> to be able to write private and internal code that cannot be called
>> explicitly in source, but can still be inlined by the compiler. Right now
>> people are doing this with underscored methods and variable names but I
>> don’t think that’s a good convention to use. We should have something at
>> the language level that enforces that something shouldn’t be referenced by
>> name outside of its scope, but is public for all compilation and ABI
>> purposes. Maybe an attribute like @visible or a new keyword or something.
>>
>
> Right, that’s @_versioned, essentially.
>
>
> On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> This is unduly restrictive; @_versioned (despite being the wrong
>>> spelling) is what we want here. To be callable from an inlinable function,
>>> internal things need only be visible in terms of public ABI, not
>>> necessarily inlinable, just as public things need only be public and not
>>> necessarily inlinable.
>>> On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution
>>>  wrote:
>>>
 On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov  wrote:

> Thanks for taking a look!
>
> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
> > 3. Even though @inlinable will have no effect on declarations which
> are not public, we should still allow it to be placed there. That way when
> the access level is later changed to be public, the attribute is already
> where it should be. This is similar to why we permit, eg., members of an
> internal type to be declared public, which was discussed and decided
> previously on Swift Evolution.
>
> This is an interesting point. Do you think the attribute should be
> completely ignored, or should the restrictions on references to non-public
> things, etc still be enforced?
>

  Hmm, good question!

 I rather like the idea Greg Parker put forth, where non-public
 @inlinable items can be used by public @inlinable ones, which implies that
 the restrictions should indeed still apply—something @inlinable can only
 reference public or @inlinable things.

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

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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Mon, Oct 2, 2017 at 17:41 Taylor Swift  wrote:

> I think we should try to separate visibility from access control. In other
> words, the compiler should be able to see more than the user. I want to be
> able to write private and internal code that cannot be called explicitly in
> source, but can still be inlined by the compiler. Right now people are
> doing this with underscored methods and variable names but I don’t think
> that’s a good convention to use. We should have something at the language
> level that enforces that something shouldn’t be referenced by name outside
> of its scope, but is public for all compilation and ABI purposes. Maybe an
> attribute like @visible or a new keyword or something.
>

Right, that’s @_versioned, essentially.


On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> This is unduly restrictive; @_versioned (despite being the wrong
>> spelling) is what we want here. To be callable from an inlinable function,
>> internal things need only be visible in terms of public ABI, not
>> necessarily inlinable, just as public things need only be public and not
>> necessarily inlinable.
>> On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov  wrote:
>>>
 Thanks for taking a look!

 > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <
 nevin.brackettrozin...@gmail.com> wrote:
 > 3. Even though @inlinable will have no effect on declarations which
 are not public, we should still allow it to be placed there. That way when
 the access level is later changed to be public, the attribute is already
 where it should be. This is similar to why we permit, eg., members of an
 internal type to be declared public, which was discussed and decided
 previously on Swift Evolution.

 This is an interesting point. Do you think the attribute should be
 completely ignored, or should the restrictions on references to non-public
 things, etc still be enforced?

>>>
>>>  Hmm, good question!
>>>
>>> I rather like the idea Greg Parker put forth, where non-public
>>> @inlinable items can be used by public @inlinable ones, which implies that
>>> the restrictions should indeed still apply—something @inlinable can only
>>> reference public or @inlinable things.
>>>
>>> Nevin
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Generics] [Pitch] Dependent Types

don’t we need something like this for Fixed Size Arrays™ too?

On Mon, Oct 2, 2017 at 6:23 PM, Félix Fischer via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi swift-evolution,
>
> I’ve been thinking for the past months of making math libraries that could
> benefit from a dependent types system (see the Wikipedia article:
> https://en.wikipedia.org/wiki/Dependent_type?wprov=sfti1). Dependent
> types would allow for the type system to enforce certain correctness in
> design that otherwise would have to be test-based. It would also discourage
> type hacks that sort of implement it, but have poor semantics and clarity.
>
> Lemme give you an example:
> - Let’s say you want to make a modulo arithmetic library. It has
> applications in cryptography, but the fields existing there can also be
> used for complete and *exact* linear algebra operations.
> - Anyway. You want to make that. How?
> - You’d want to have a struct that represented a number from a modulo
> field.
> - These numbers can be multiplied, added, have inverses, etc.
> - But those operations only make sense if the prime P used for the modulo
> operation is the same between them. Otherwise, what’s the point?
> —> (Basically, you can’t just add (2 modulo 3) with (3 modulo 5). It
> doesn’t make sense)
> - You could do this in many different ways, and only a few (very hacky,
> “static class in a where clause”-like) will actually enforce this condition
> from the type system, which afaik is usually the best way to do so; both at
> compile time and at run time.
>
> On the other hand, having dependent types allows you to have exactly this
> kind of behavior:
> - Now you can define a “dependent type”, for example ModuloInteger,
> where P is the integer value that defines the type.
> - Like this, you’ll have:
> —> MI<2>: {0, 1}, where 1 + 1 = 0.
> —> MI<3>: {0, 1, 2}, where 1 + 1 = 2, and 2 • 2 = 1
> —> ... and so on.
> - Such a type system can be used for even stronger type qualities (read
> the Wikipedia article for good examples).
> - Such strong type qualities are super nice for any critical systems and
> for math libraries in general.
> - And I guess for just general correctness and documentation. It gives
> better semantics to our types.
>
> So, what do you say? Is this too crazy?
>
> Cheers,
> Félix
>
> Btw if you know Haskell (which I don’t, but appreciate), you can check a
> decent, Haskell-inspired, dependently typed language... here ~>
> https://www.idris-lang.org/
>
> ___
> 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] [Generics] [Pitch] Dependent Types

2017-10-02 Thread Félix Fischer via swift-evolution

Hi swift-evolution,

I’ve been thinking for the past months of making math libraries that could
benefit from a dependent types system (see the Wikipedia article:
https://en.wikipedia.org/wiki/Dependent_type?wprov=sfti1). Dependent types
would allow for the type system to enforce certain correctness in design
that otherwise would have to be test-based. It would also discourage type
hacks that sort of implement it, but have poor semantics and clarity.

Lemme give you an example:
- Let’s say you want to make a modulo arithmetic library. It has
applications in cryptography, but the fields existing there can also be
used for complete and *exact* linear algebra operations.
- Anyway. You want to make that. How?
- You’d want to have a struct that represented a number from a modulo field.
- These numbers can be multiplied, added, have inverses, etc.
- But those operations only make sense if the prime P used for the modulo
operation is the same between them. Otherwise, what’s the point?
—> (Basically, you can’t just add (2 modulo 3) with (3 modulo 5). It
doesn’t make sense)
- You could do this in many different ways, and only a few (very hacky,
“static class in a where clause”-like) will actually enforce this condition
from the type system, which afaik is usually the best way to do so; both at
compile time and at run time.

On the other hand, having dependent types allows you to have exactly this
kind of behavior:
- Now you can define a “dependent type”, for example ModuloInteger,
where P is the integer value that defines the type.
- Like this, you’ll have:
—> MI<2>: {0, 1}, where 1 + 1 = 0.
—> MI<3>: {0, 1, 2}, where 1 + 1 = 2, and 2 • 2 = 1
—> ... and so on.
- Such a type system can be used for even stronger type qualities (read the
Wikipedia article for good examples).
- Such strong type qualities are super nice for any critical systems and
for math libraries in general.
- And I guess for just general correctness and documentation. It gives
better semantics to our types.

So, what do you say? Is this too crazy?

Cheers,
Félix

Btw if you know Haskell (which I don’t, but appreciate), you can check a
decent, Haskell-inspired, dependently typed language... here ~>
https://www.idris-lang.org/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

This is something I’ve been waiting for for a long time and I’m glad this
is finally becoming a reality. This is a big step forward for anyone
interested in seeing Swift get core “almost-stdlib” libraries.

On Mon, Oct 2, 2017 at 3:31 PM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> Here is a draft proposal that makes public a feature we’ve had for a
> while. Let me know what you think!
>
> Cross-module inlining and specialization ("@inlinable")
>
>- Proposal: SE-
>- Authors: Slava Pestov , Jordan Rose
>
>- Review Manager: TBD
>- Status: *Initial pitch*
>- Implementation: Already implemented as an underscored attribute
>@_inlineable
>
> Introduction
>
> We propose introducing an @inlinable attribute which exports the body of
> a function as part of a module's interface, making it available to the
> optimizer when referenced from other modules.
> Motivation
>
> One of the top priorities of the Swift 5 release is a design and
> implementation of *the Swift ABI*. This effort consists of three major
> tasks:
>
>-
>
>Finalizing the low-level function calling convention, layout of data
>types, and various runtime data structures. The goal here is to maintain
>compatibility across compiler versions, ensuring that we can continue to
>make improvements to the Swift compiler without breaking binaries built
>with an older version of the compiler.
>-
>
>Implementing support for *library evolution*, or the ability to make
>certain source-compatible changes, without breaking binary compatibility.
>Examples of source-compatible changes we are considering include adding new
>stored properties to structs and classes, removing private stored
>properties from structs and classes, adding new public methods to a class,
>or adding new protocol requirements that have a default implementation. The
>goal here is to maintain compatibility across framework versions, ensuring
>that framework authors can evolve their API without breaking binaries built
>against an older version of the framework. For more information about the
>resilience model, see the library evolution document
> in
>the Swift repository.
>-
>
>Stabilizing the API of the standard library. The goal here is to
>ensure that the standard library can be deployed separately from client
>binaries and frameworks, without forcing recompilation of existing code.
>
> All existing language features of Swift were designed with these goals in
> mind. In particular, the implementation of generic types and functions
> relies on runtime reified types to allow separate compilation and type
> checking of generic code.
>
> Within the scope of a single module, the Swift compiler performs very
> aggressive optimization, including full and partial specialization of
> generic functions, inlining, and various forms of interprocedural analysis.
>
> On the other hand, across module boundaries, runtime generics introduce
> unavoidable overhead, as reified type metadata must be passed between
> functions, and various indirect access patterns must be used to manipulate
> values of generic type. We believe that for most applications, this
> overhead is negligible compared to the actual work performed by the code
> itself.
>
> However, for some advanced use cases, and in particular for the standard
> library, the overhead of runtime generics can dominate any useful work
> performed by the library. Examples include the various algorithms defined
> in protocol extensions of Sequence and Collection, for instance the mapmethod
> of the Sequence protocol. Here the algorithm is very simple and spends
> most of its time manipulating generic values and calling to a user-supplied
> closure; specialization and inlining can completely eliminate the algorithm
> of the higher-order function call and generate equivalent code to a
> hand-written loop manipulating concrete types.
>
> We would like to annotate such functions with the @inlinable attribute.
> This will make their bodies available to the optimizer when building client
> code; on the other hand, calling such a function will cause it to be
> emitted into the client binary, meaning that if a library were to change
> the definition of such a function, only binaries built against the newer
> version of library will use the new definition.
> Proposed solution
>
> The @inlinable attribute causes the body of a function to be emitted as
> part of the module interface. For example, a framework can define a rather
> impractical implementation of an algorithm which returns true if all
> elements of a sequence are equal or if the sequence is empty, and false
> otherwise:
>
> @inlinable public func allEqual(_ seq: T) -> Bool
> where T : Sequence, T.Element : Equatable {

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

I think we should try to separate visibility from access control. In other
words, the compiler should be able to see more than the user. I want to be
able to write private and internal code that cannot be called explicitly in
source, but can still be inlined by the compiler. Right now people are
doing this with underscored methods and variable names but I don’t think
that’s a good convention to use. We should have something at the language
level that enforces that something shouldn’t be referenced by name outside
of its scope, but is public for all compilation and ABI purposes. Maybe an
attribute like @visible or a new keyword or something.

On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> This is unduly restrictive; @_versioned (despite being the wrong spelling)
> is what we want here. To be callable from an inlinable function, internal
> things need only be visible in terms of public ABI, not necessarily
> inlinable, just as public things need only be public and not necessarily
> inlinable.
> On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov  wrote:
>>
>>> Thanks for taking a look!
>>>
>>> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <
>>> nevin.brackettrozin...@gmail.com> wrote:
>>> > 3. Even though @inlinable will have no effect on declarations which
>>> are not public, we should still allow it to be placed there. That way when
>>> the access level is later changed to be public, the attribute is already
>>> where it should be. This is similar to why we permit, eg., members of an
>>> internal type to be declared public, which was discussed and decided
>>> previously on Swift Evolution.
>>>
>>> This is an interesting point. Do you think the attribute should be
>>> completely ignored, or should the restrictions on references to non-public
>>> things, etc still be enforced?
>>>
>>
>>  Hmm, good question!
>>
>> I rather like the idea Greg Parker put forth, where non-public @inlinable
>> items can be used by public @inlinable ones, which implies that the
>> restrictions should indeed still apply—something @inlinable can only
>> reference public or @inlinable things.
>>
>> Nevin
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris  wrote:

>
> On Oct 2, 2017, at 09:14, Xiaodi Wu  wrote:
>
> What is your use case for this?
>
> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi All.
>>
>> I’d like to help as well. I have fun with operators.
>>
>> There is also the issue of code security with invisible unicode
>> characters and characters that look exactly alike.
>>
>>
>> Unless there is a compelling reason to add them, I think we should ban
>> invisible characters.  What is the harm of characters that look alike?
>>
>>
>> Especially if people want to use the character in question as both an
>> identifier and an operator: We can make the character an identifier and its
>> lookalike an operator (or the other way around).
>>
>
> Off the top of my head...
> In calculus, “𝖽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine
> substitute for "d" in “𝖽y/𝖽x” ("the derivative of y(x) with respect to
> x").
> In statistics, we could use "𝖢" (MATHEMATICAL SANS-SERIF CAPITAL C), as
> in "5𝖢3" to mimic the "5C3" notation ("5 choose 3"). And although not
> strictly an issue of identifiers vs operators, “！” (FULLWIDTH EXCLAMATION
> MARK) would be an ok substitution (that extra space on the right looks
> funny) for "!" in “4！” ("4 factorial").
>
> I'm sure there are other examples from math/science/ "symbology"-heavy DSL here>, but “d” in particular is one that I’ve wanted
> for a while since Swift classifies "∂" (the partial derivative operator) as
> an operator rather than an identifier, making it impossible to use a
> consistent syntax between normal derivatives and partial derivatives
> (normal derivatives are "d(y)/d(x)", whereas partial derivatives get to
> drop the parens "∂y/∂x")
>

Allowing a custom operator that looks like `!` to be anything other than
the force-unwrap operator would be unwise, IMO, and not a desirable goal.
Likewise characters that look like `d` not being the character `d`, etc. In
the previous PR, the authors deliberately created a system where these will
not be possible.

I think we should specify from the outset of re-examining this topic that
supporting arbitrary math/science notation without demonstrable improvement
in code clarity for actual, Swift code is a non-goal. Since manipulating
matrices is a common programming task, and the current BLAS syntax is
terribly cumbersome, being able to use operators for matrix multiplication,
inversion, etc. is imminently reasonable. Having a way of writing
`4.factorial()` that looks like an equation in a math textbook, however,
wouldn't pass that bar.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

2017-10-02 Thread Nevin Brackett-Rozinsky via swift-evolution

This is unduly restrictive; @_versioned (despite being the wrong spelling)
is what we want here. To be callable from an inlinable function, internal
things need only be visible in terms of public ABI, not necessarily
inlinable, just as public things need only be public and not necessarily
inlinable.
On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov  wrote:
>
>> Thanks for taking a look!
>>
>> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <
>> nevin.brackettrozin...@gmail.com> wrote:
>> > 3. Even though @inlinable will have no effect on declarations which are
>> not public, we should still allow it to be placed there. That way when the
>> access level is later changed to be public, the attribute is already where
>> it should be. This is similar to why we permit, eg., members of an internal
>> type to be declared public, which was discussed and decided previously on
>> Swift Evolution.
>>
>> This is an interesting point. Do you think the attribute should be
>> completely ignored, or should the restrictions on references to non-public
>> things, etc still be enforced?
>>
>
>  Hmm, good question!
>
> I rather like the idea Greg Parker put forth, where non-public @inlinable
> items can be used by public @inlinable ones, which implies that the
> restrictions should indeed still apply—something @inlinable can only
> reference public or @inlinable things.
>
> Nevin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov  wrote:

> Thanks for taking a look!
>
> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
> > 3. Even though @inlinable will have no effect on declarations which are
> not public, we should still allow it to be placed there. That way when the
> access level is later changed to be public, the attribute is already where
> it should be. This is similar to why we permit, eg., members of an internal
> type to be declared public, which was discussed and decided previously on
> Swift Evolution.
>
> This is an interesting point. Do you think the attribute should be
> completely ignored, or should the restrictions on references to non-public
> things, etc still be enforced?
>

 Hmm, good question!

I rather like the idea Greg Parker put forth, where non-public @inlinable
items can be used by public @inlinable ones, which implies that the
restrictions should indeed still apply—something @inlinable can only
reference public or @inlinable things.

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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization


> On Oct 2, 2017, at 2:20 PM, Greg Parker  wrote:
> 
> 
>> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> inlinable declarations can only reference other public declarations. This is 
>> because they can be emitted into the client binary, and are therefore 
>> limited to referencing symbols that the client binary can reference.
>> 
> 
> Private @inlinable functions are useful. For example, you might want a helper 
> function to be inlined into a public @inlinable function for performance, but 
> you don't want that helper function to be called by outside clients directly. 
> 
> The restriction would then be "inlinable declarations can only reference 
> other public declarations and other @inlinable non-public declarations". This 
> relaxation would have no affect on ABI: only @inlinable things could be 
> inlined, and only public things could be ultimately referenced by inlined 
> things. 
> 
> Having said that, it should be fine to use "public @inlinable only" for now 
> and consider relaxing the restriction later.

That’s what @_versioned is currently for. You can define a function as 
@_versioned @_inlineable and reference it from other public inlinable 
functions, without making it visible to AST-level lookup.

While I would prefer to punt formalizing  this to a future proposal, we can 
still design the correct spelling and behavior of @_versioned here (I’m pretty 
sure the current attribute isn’t it).

Slava

> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 

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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

2017-10-02 Thread Nevin Brackett-Rozinsky via swift-evolution

Thanks for taking a look!

> On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky 
>  wrote:
> 
> I am hugely in favor of an @inlinable attribute, and I look forward to its 
> arrival with relish!
> 
> Some feedback:
> 
> 1. I think “inlinable” is the right spelling: it indicates that something is 
> *able* to be inlined.

Yeah, it seems this is the spelling we’re going to go with.

> 
> 2. If I want to pass an @inlinable function as an argument (say, to map or 
> filter) can I do so directly or must I use a closure which calls the 
> inlinable function?

You can pass it directly. From the viewpoint of code that uses an inlinable 
function, it behaves exactly the same as one that does not have the attribute.

> 3. Even though @inlinable will have no effect on declarations which are not 
> public, we should still allow it to be placed there. That way when the access 
> level is later changed to be public, the attribute is already where it should 
> be. This is similar to why we permit, eg., members of an internal type to be 
> declared public, which was discussed and decided previously on Swift 
> Evolution.

This is an interesting point. Do you think the attribute should be completely 
ignored, or should the restrictions on references to non-public things, etc 
still be enforced?

Slava

> 
> Other than that the proposal looks great, thanks for writing it up.
> 
> Nevin

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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

2017-10-02 Thread Greg Parker via swift-evolution

> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution 
>  wrote:
> inlinable declarations can only reference other public declarations. This is 
> because they can be emitted into the client binary, and are therefore limited 
> to referencing symbols that the client binary can reference.
> 

Private @inlinable functions are useful. For example, you might want a helper 
function to be inlined into a public @inlinable function for performance, but 
you don't want that helper function to be called by outside clients directly. 

The restriction would then be "inlinable declarations can only reference other 
public declarations and other @inlinable non-public declarations". This 
relaxation would have no affect on ABI: only @inlinable things could be 
inlined, and only public things could be ultimately referenced by inlined 
things. 

Having said that, it should be fine to use "public @inlinable only" for now and 
consider relaxing the restriction later.

-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler

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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

I am hugely in favor of an @inlinable attribute, and I look forward to its
arrival with relish!

Some feedback:

1. I think “inlinable” is the right spelling: it indicates that something
is *able* to be inlined.

2. If I want to pass an @inlinable function as an argument (say, to map or
filter) can I do so directly or must I use a closure which calls the
inlinable function?

3. Even though @inlinable will have no effect on declarations which are not
public, we should still allow it to be placed there. That way when the
access level is later changed to be public, the attribute is already where
it should be. This is similar to why we permit, eg., members of an internal
type to be declared public, which was discussed and decided previously on
Swift Evolution.

Other than that the proposal looks great, thanks for writing it up.

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

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Today's @available can't be the thing that makes symbols public, since it's 
also used to affect the availability context for private symbols. The one 
described in the library evolution document is specifically about marking 
something available with respect to the current module. So we would want 
another spelling.

(But it definitely shouldn't be "_versioned", which doesn't mean anything if we 
don't have "versions".)

Jordan


> On Oct 2, 2017, at 13:47, Slava Pestov via swift-evolution 
>  wrote:
> 
> Thanks for taking a look.
> 
> @_versioned is not something we want to keep in the long term. The original 
> idea was to allow @available annotations to be put on internal declarations, 
> which would have the effect of giving their symbols public linkage. I think a 
> follow-up proposal could introduce this feature as well as “conditionally 
> available inlinable”, which I describe in document below. However if people 
> feel strongly we could roll both of them into this proposal, but it would 
> require some more implementation work.
> 
> Slava
> 
>> On Oct 2, 2017, at 1:44 PM, Xiaodi Wu > > wrote:
>> 
>> Very much looking forward to this. Any possibility of rolling in some 
>> version (ha) of @_versioned so that @inlinable functions can reference 
>> internal declarations?
>> 
>> 
>> On Mon, Oct 2, 2017 at 3:31 PM, Slava Pestov via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Hi all,
>> 
>> Here is a draft proposal that makes public a feature we’ve had for a while. 
>> Let me know what you think!
>> 
>> Cross-module inlining and specialization ("@inlinable")
>> Proposal: SE- <>
>> Authors: Slava Pestov , Jordan Rose 
>> 
>> Review Manager: TBD
>> Status: Initial pitch
>> Implementation: Already implemented as an underscored attribute @_inlineable
>> Introduction
>> We propose introducing an @inlinable attribute which exports the body of a 
>> function as part of a module's interface, making it available to the 
>> optimizer when referenced from other modules.
>> 
>> Motivation
>> One of the top priorities of the Swift 5 release is a design and 
>> implementation of the Swift ABI. This effort consists of three major tasks:
>> 
>> Finalizing the low-level function calling convention, layout of data types, 
>> and various runtime data structures. The goal here is to maintain 
>> compatibility across compiler versions, ensuring that we can continue to 
>> make improvements to the Swift compiler without breaking binaries built with 
>> an older version of the compiler.
>> 
>> Implementing support for library evolution, or the ability to make certain 
>> source-compatible changes, without breaking binary compatibility. Examples 
>> of source-compatible changes we are considering include adding new stored 
>> properties to structs and classes, removing private stored properties from 
>> structs and classes, adding new public methods to a class, or adding new 
>> protocol requirements that have a default implementation. The goal here is 
>> to maintain compatibility across framework versions, ensuring that framework 
>> authors can evolve their API without breaking binaries built against an 
>> older version of the framework. For more information about the resilience 
>> model, see the library evolution document 
>>  in 
>> the Swift repository.
>> 
>> Stabilizing the API of the standard library. The goal here is to ensure that 
>> the standard library can be deployed separately from client binaries and 
>> frameworks, without forcing recompilation of existing code.
>> 
>> All existing language features of Swift were designed with these goals in 
>> mind. In particular, the implementation of generic types and functions 
>> relies on runtime reified types to allow separate compilation and type 
>> checking of generic code.
>> 
>> Within the scope of a single module, the Swift compiler performs very 
>> aggressive optimization, including full and partial specialization of 
>> generic functions, inlining, and various forms of interprocedural analysis.
>> 
>> On the other hand, across module boundaries, runtime generics introduce 
>> unavoidable overhead, as reified type metadata must be passed between 
>> functions, and various indirect access patterns must be used to manipulate 
>> values of generic type. We believe that for most applications, this overhead 
>> is negligible compared to the actual work performed by the code itself.
>> 
>> However, for some advanced use cases, and in particular for the standard 
>> library, the overhead of runtime generics can dominate any useful work 
>> performed by the library. Examples include the various algorithms defined in 
>> protocol extensions of Sequence and Collection, for instance the mapmethod 
>> of the Sequence protocol. Here the algorithm is very simple and spends most 
>> of i

Re: [swift-evolution] Enums and Source Compatibility

I don't think I have anything to say on this topic that I haven't already said:

- Switching exhaustively over non-exhaustive enums is uncommon.
- It's more important for a library to build without errors when its 
dependencies change than it is to get an error. (This doesn't apply to 
warnings, though.)
- Untestable code is dangerous, so having a language feature inherently for 
untestable code seems bad.

None of that negates your points; it just affects the weighting of whether or 
not 'future' or 'switch!' is worth it. However, I've added a link to your email 
in the proposal proper so that the Core Team and wider review audience have a 
chance to decide differently.

Jordan


> On Oct 2, 2017, at 08:25, Vladimir.S via swift-evolution 
>  wrote:
> 
> 
> Sorry to bother, but I still can't understand how the proposed change 
> *without* a 'future' case in switch will change our life and what would be 
> our steps to support our code and to not make our code buggy.
> If I misunderstand something - sorry, please point me on this and I hope this 
> also help some one like me to understand the subject better.
> 
> For example. I use OAuth2 framework, built by Carthage. Did add the 
> OAuth2.framework to my project.
> 
> Currently OAuth2 exports 'public enum OAuth2Error'. I do have a place in my 
> code where I switch on each case of such error instance to do my best with 
> error: generate detailed description for user, other additional steps 
> depending on error.
> 
> Will/should author of OAuth2 make OAuth2Error 'exhaustive' ? No.
> Will new cases be added to that enum in future: Most likely Yes.
> Do I need to switch on each case in my code? Yes.
> Can I currently rely on compiler to keep my error processing in sync with 
> error cases defined in framework? Yes.
> Can new cases appear in *run-time* of my app: NO, framework in embedded.
> Will I be able to rely on compiler after the proposed change? No?!
> What should I do to keep my switch in sync with OAuth2Error cases after each 
> update of OAuth2 library(framework)? Manually check if new cases are added?! 
> Configure lint/other tools to help me with this?!
> 
> What I, as a developer, as a consumer of framework, need - is a way to 
> exhaustively switch on *some* external non-exhaustive enums *at the moment of 
> compilation*. And we can accomplish this only(AFAICT) with 'future' case in 
> 'switch'.
> In case we'll have 'future' case my life will not be *worse* for this project 
> : I'll add it to my switch and still can receive help from compiler to keep 
> switch exhaustive.
> 
> I don't support the opinion that we can't introduce 'future' case because of 
> we can't test it:
> 
> 1. Not being able to keep my switch exhaustive when I need this, and so not 
> being able to provide users of my app with best experience - IMO is worse.
> 2. In my particular example, 'future' case will be *never* called, if I 
> understand correctly.
> 3. If switch on non-exhaustive enum is exhaustive by fact, we can't test the 
> 'default' branch also. So, 'future' is in same position here with 'default'
> 4. I believe if we'll decide we need 'future' case - we can suggest a way to 
> call code in that case during the test process.
> 
> Seems like for embedded frameworks we should apply the same rules(regarding 
> enums) as for sources, as we compile the app with concrete binary of 
> framework and there just can't be new cases in enums. No?
> 
> Thank you for your time.
> Vladimir.
> 
> On 01.10.2017 3:00, Slava Pestov via swift-evolution wrote:
>>> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I don’t see how it’s impractical. Quite a lot about how the library should 
>>> be optimally compiled and used depends on what you plan to do with it. If 
>>> it’s going to be installed somewhere private and you can guarantee clients 
>>> will always have the latest version, you can assume all data types are 
>>> final, @_fixed_layout, @exhaustive, whatever (essentially in-module). An 
>>> example of that would be a library embedded inside an iOS app bundle. If 
>>> it’s going to be installed somewhere public and expose some API (like 
>>> Apple’s frameworks), then you’re going to have to think about binary 
>>> compatibility.
>>> 
>>> That also means that in-app libraries are optimised as much as they can be, 
>>> and that resilience-related changes on the declaration side can be limited 
>>> to the limited set of Swift developers who truly have to care about that.
>> We do plan on exposing an -enable-resilience flag which basically does what 
>> you describe. When a library is built without -enable-resilience, all types 
>> are assumed to be fixed layout, etc. However, we don’t want language flags 
>> to change language semantics, so exhaustive/nonexhaustive still make sense 
>> even when building without resilience, I think. When you switch over a 
>> non-exhaustive enum that came from a library built w

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Thanks for taking a look.

@_versioned is not something we want to keep in the long term. The original 
idea was to allow @available annotations to be put on internal declarations, 
which would have the effect of giving their symbols public linkage. I think a 
follow-up proposal could introduce this feature as well as “conditionally 
available inlinable”, which I describe in document below. However if people 
feel strongly we could roll both of them into this proposal, but it would 
require some more implementation work.

Slava

> On Oct 2, 2017, at 1:44 PM, Xiaodi Wu  wrote:
> 
> Very much looking forward to this. Any possibility of rolling in some version 
> (ha) of @_versioned so that @inlinable functions can reference internal 
> declarations?
> 
> 
> On Mon, Oct 2, 2017 at 3:31 PM, Slava Pestov via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Hi all,
> 
> Here is a draft proposal that makes public a feature we’ve had for a while. 
> Let me know what you think!
> 
> Cross-module inlining and specialization ("@inlinable")
> Proposal: SE- <>
> Authors: Slava Pestov , Jordan Rose 
> 
> Review Manager: TBD
> Status: Initial pitch
> Implementation: Already implemented as an underscored attribute @_inlineable
> Introduction
> We propose introducing an @inlinable attribute which exports the body of a 
> function as part of a module's interface, making it available to the 
> optimizer when referenced from other modules.
> 
> Motivation
> One of the top priorities of the Swift 5 release is a design and 
> implementation of the Swift ABI. This effort consists of three major tasks:
> 
> Finalizing the low-level function calling convention, layout of data types, 
> and various runtime data structures. The goal here is to maintain 
> compatibility across compiler versions, ensuring that we can continue to make 
> improvements to the Swift compiler without breaking binaries built with an 
> older version of the compiler.
> 
> Implementing support for library evolution, or the ability to make certain 
> source-compatible changes, without breaking binary compatibility. Examples of 
> source-compatible changes we are considering include adding new stored 
> properties to structs and classes, removing private stored properties from 
> structs and classes, adding new public methods to a class, or adding new 
> protocol requirements that have a default implementation. The goal here is to 
> maintain compatibility across framework versions, ensuring that framework 
> authors can evolve their API without breaking binaries built against an older 
> version of the framework. For more information about the resilience model, 
> see the library evolution document 
>  in the 
> Swift repository.
> 
> Stabilizing the API of the standard library. The goal here is to ensure that 
> the standard library can be deployed separately from client binaries and 
> frameworks, without forcing recompilation of existing code.
> 
> All existing language features of Swift were designed with these goals in 
> mind. In particular, the implementation of generic types and functions relies 
> on runtime reified types to allow separate compilation and type checking of 
> generic code.
> 
> Within the scope of a single module, the Swift compiler performs very 
> aggressive optimization, including full and partial specialization of generic 
> functions, inlining, and various forms of interprocedural analysis.
> 
> On the other hand, across module boundaries, runtime generics introduce 
> unavoidable overhead, as reified type metadata must be passed between 
> functions, and various indirect access patterns must be used to manipulate 
> values of generic type. We believe that for most applications, this overhead 
> is negligible compared to the actual work performed by the code itself.
> 
> However, for some advanced use cases, and in particular for the standard 
> library, the overhead of runtime generics can dominate any useful work 
> performed by the library. Examples include the various algorithms defined in 
> protocol extensions of Sequence and Collection, for instance the mapmethod of 
> the Sequence protocol. Here the algorithm is very simple and spends most of 
> its time manipulating generic values and calling to a user-supplied closure; 
> specialization and inlining can completely eliminate the algorithm of the 
> higher-order function call and generate equivalent code to a hand-written 
> loop manipulating concrete types.
> 
> We would like to annotate such functions with the @inlinable attribute. This 
> will make their bodies available to the optimizer when building client code; 
> on the other hand, calling such a function will cause it to be emitted into 
> the client binary, meaning that if a library were to change the definition of 
> such a function, only binaries built against th

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Very much looking forward to this. Any possibility of rolling in some
version (ha) of @_versioned so that @inlinable functions can reference
internal declarations?


On Mon, Oct 2, 2017 at 3:31 PM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> Here is a draft proposal that makes public a feature we’ve had for a
> while. Let me know what you think!
>
> Cross-module inlining and specialization ("@inlinable")
>
>- Proposal: SE-
>- Authors: Slava Pestov , Jordan Rose
>
>- Review Manager: TBD
>- Status: *Initial pitch*
>- Implementation: Already implemented as an underscored attribute
>@_inlineable
>
> Introduction
>
> We propose introducing an @inlinable attribute which exports the body of
> a function as part of a module's interface, making it available to the
> optimizer when referenced from other modules.
> Motivation
>
> One of the top priorities of the Swift 5 release is a design and
> implementation of *the Swift ABI*. This effort consists of three major
> tasks:
>
>-
>
>Finalizing the low-level function calling convention, layout of data
>types, and various runtime data structures. The goal here is to maintain
>compatibility across compiler versions, ensuring that we can continue to
>make improvements to the Swift compiler without breaking binaries built
>with an older version of the compiler.
>-
>
>Implementing support for *library evolution*, or the ability to make
>certain source-compatible changes, without breaking binary compatibility.
>Examples of source-compatible changes we are considering include adding new
>stored properties to structs and classes, removing private stored
>properties from structs and classes, adding new public methods to a class,
>or adding new protocol requirements that have a default implementation. The
>goal here is to maintain compatibility across framework versions, ensuring
>that framework authors can evolve their API without breaking binaries built
>against an older version of the framework. For more information about the
>resilience model, see the library evolution document
> in
>the Swift repository.
>-
>
>Stabilizing the API of the standard library. The goal here is to
>ensure that the standard library can be deployed separately from client
>binaries and frameworks, without forcing recompilation of existing code.
>
> All existing language features of Swift were designed with these goals in
> mind. In particular, the implementation of generic types and functions
> relies on runtime reified types to allow separate compilation and type
> checking of generic code.
>
> Within the scope of a single module, the Swift compiler performs very
> aggressive optimization, including full and partial specialization of
> generic functions, inlining, and various forms of interprocedural analysis.
>
> On the other hand, across module boundaries, runtime generics introduce
> unavoidable overhead, as reified type metadata must be passed between
> functions, and various indirect access patterns must be used to manipulate
> values of generic type. We believe that for most applications, this
> overhead is negligible compared to the actual work performed by the code
> itself.
>
> However, for some advanced use cases, and in particular for the standard
> library, the overhead of runtime generics can dominate any useful work
> performed by the library. Examples include the various algorithms defined
> in protocol extensions of Sequence and Collection, for instance the mapmethod
> of the Sequence protocol. Here the algorithm is very simple and spends
> most of its time manipulating generic values and calling to a user-supplied
> closure; specialization and inlining can completely eliminate the algorithm
> of the higher-order function call and generate equivalent code to a
> hand-written loop manipulating concrete types.
>
> We would like to annotate such functions with the @inlinable attribute.
> This will make their bodies available to the optimizer when building client
> code; on the other hand, calling such a function will cause it to be
> emitted into the client binary, meaning that if a library were to change
> the definition of such a function, only binaries built against the newer
> version of library will use the new definition.
> Proposed solution
>
> The @inlinable attribute causes the body of a function to be emitted as
> part of the module interface. For example, a framework can define a rather
> impractical implementation of an algorithm which returns true if all
> elements of a sequence are equal or if the sequence is empty, and false
> otherwise:
>
> @inlinable public func allEqual(_ seq: T) -> Bool
> where T : Sequence, T.Element : Equatable {
>   var iter = seq.makeIterator()
>   gu

[swift-evolution] Pitch: Cross-module inlining and specialization

Hi all,

Here is a draft proposal that makes public a feature we’ve had for a while. Let 
me know what you think!

Cross-module inlining and specialization ("@inlinable")
Proposal: SE- 
Authors: Slava Pestov , Jordan Rose 

Review Manager: TBD
Status: Initial pitch
Implementation: Already implemented as an underscored attribute @_inlineable
Introduction
We propose introducing an @inlinable attribute which exports the body of a 
function as part of a module's interface, making it available to the optimizer 
when referenced from other modules.

Motivation
One of the top priorities of the Swift 5 release is a design and implementation 
of the Swift ABI. This effort consists of three major tasks:

Finalizing the low-level function calling convention, layout of data types, and 
various runtime data structures. The goal here is to maintain compatibility 
across compiler versions, ensuring that we can continue to make improvements to 
the Swift compiler without breaking binaries built with an older version of the 
compiler.

Implementing support for library evolution, or the ability to make certain 
source-compatible changes, without breaking binary compatibility. Examples of 
source-compatible changes we are considering include adding new stored 
properties to structs and classes, removing private stored properties from 
structs and classes, adding new public methods to a class, or adding new 
protocol requirements that have a default implementation. The goal here is to 
maintain compatibility across framework versions, ensuring that framework 
authors can evolve their API without breaking binaries built against an older 
version of the framework. For more information about the resilience model, see 
the library evolution document 
 in the 
Swift repository.

Stabilizing the API of the standard library. The goal here is to ensure that 
the standard library can be deployed separately from client binaries and 
frameworks, without forcing recompilation of existing code.

All existing language features of Swift were designed with these goals in mind. 
In particular, the implementation of generic types and functions relies on 
runtime reified types to allow separate compilation and type checking of 
generic code.

Within the scope of a single module, the Swift compiler performs very 
aggressive optimization, including full and partial specialization of generic 
functions, inlining, and various forms of interprocedural analysis.

On the other hand, across module boundaries, runtime generics introduce 
unavoidable overhead, as reified type metadata must be passed between 
functions, and various indirect access patterns must be used to manipulate 
values of generic type. We believe that for most applications, this overhead is 
negligible compared to the actual work performed by the code itself.

However, for some advanced use cases, and in particular for the standard 
library, the overhead of runtime generics can dominate any useful work 
performed by the library. Examples include the various algorithms defined in 
protocol extensions of Sequence and Collection, for instance the mapmethod of 
the Sequence protocol. Here the algorithm is very simple and spends most of its 
time manipulating generic values and calling to a user-supplied closure; 
specialization and inlining can completely eliminate the algorithm of the 
higher-order function call and generate equivalent code to a hand-written loop 
manipulating concrete types.

We would like to annotate such functions with the @inlinable attribute. This 
will make their bodies available to the optimizer when building client code; on 
the other hand, calling such a function will cause it to be emitted into the 
client binary, meaning that if a library were to change the definition of such 
a function, only binaries built against the newer version of library will use 
the new definition.

Proposed solution
The @inlinable attribute causes the body of a function to be emitted as part of 
the module interface. For example, a framework can define a rather impractical 
implementation of an algorithm which returns true if all elements of a sequence 
are equal or if the sequence is empty, and falseotherwise:

@inlinable public func allEqual(_ seq: T) -> Bool
where T : Sequence, T.Element : Equatable {
  var iter = seq.makeIterator()
  guard let first = iter.next() else { return true }

  func rec(_ iter: inout T.Iterator) -> Bool {
guard let next = iter.next() else { return true }
return next == first && rec(&iter)
  }

  return rec(&iter)
}
A client binary built against this framework can call allEqual() and enjoy a 
possible performance improvement when built with optimizations enabled, due to 
the elimination of abstraction overhead.

On the other hand, once the framework author comes to their senses and 
implements an iterative s

Re: [swift-evolution] Enums and Source Compatibility

This exists, but it's imperfect: it's possible that an app and its embedded 
frameworks are not all linked against the same version of the SDK, and then the 
system framework has to go with whatever the app does. (It's more important to 
behave consistently within a process.)

It's not impossible to design something like this for Swift and even for 
third-party frameworks, but that particular limitation is inherent. It also 
doesn't always make sense to try to emulate the old behavior—in the first 
system that gains support for DVDs, it's not really worth pretending that 
they're CDs or floppy disks.  I contend that non-exhaustive enums are a fact of 
life for OS frameworks, and still a good thing for open source frameworks.

Jordan

> On Oct 2, 2017, at 10:29, Wallacy via swift-evolution 
>  wrote:
> 
> @Slava
> 
> If my understanding is correct. If I compile my application with the x.y.z 
> version of a Apple System Framework (like Cocoa). And this framework is 
> updated, several calls from my application to the "new" framework version 
> x.z.a behave like in the x.y.z version for compatibility issues right? I see 
> this being mentioned in the Cocoa documentations sometimes.
> 
> Is possible to do this here?
> 
> I usually don't care about non-exhaustive enums. We avoid this even in 
> languages which do not enforce us (using external tools sometimes). But i can 
> understand the "need" in some projects.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

2017-10-02 Thread David Sweeris via swift-evolution


On Oct 2, 2017, at 09:14, Xiaodi Wu mailto:xiaodi...@gmail.com>> wrote:

> What is your use case for this?
> 
> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi All.
>>> 
>>> I’d like to help as well. I have fun with operators.
>>> 
>>> There is also the issue of code security with invisible unicode characters 
>>> and characters that look exactly alike.
>> 
>> Unless there is a compelling reason to add them, I think we should ban 
>> invisible characters.  What is the harm of characters that look alike?
> 
> Especially if people want to use the character in question as both an 
> identifier and an operator: We can make the character an identifier and its 
> lookalike an operator (or the other way around).

Off the top of my head...
In calculus, “𝖽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine substitute 
for "d" in “𝖽y/𝖽x” ("the derivative of y(x) with respect to x").
In statistics, we could use "𝖢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in 
"5𝖢3" to mimic the "5C3" notation ("5 choose 3"). And although not strictly an 
issue of identifiers vs operators, “！” (FULLWIDTH EXCLAMATION MARK) would be an 
ok substitution (that extra space on the right looks funny) for "!" in “4！” ("4 
factorial").

I'm sure there are other examples from math/science/, but “d” in particular is one that I’ve wanted for 
a while since Swift classifies "∂" (the partial derivative operator) as an 
operator rather than an identifier, making it impossible to use a consistent 
syntax between normal derivatives and partial derivatives (normal derivatives 
are "d(y)/d(x)", whereas partial derivatives get to drop the parens "∂y/∂x")

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

Re: [swift-evolution] Enums and Source Compatibility

2017-10-02 Thread Dave DeLong via swift-evolution



> On Oct 2, 2017, at 11:29 AM, Wallacy via swift-evolution 
>  wrote:
> 
> @Slava
> 
> If my understanding is correct. If I compile my application with the x.y.z 
> version of a Apple System Framework (like Cocoa). And this framework is 
> updated, several calls from my application to the "new" framework version 
> x.z.a behave like in the x.y.z version for compatibility issues right? I see 
> this being mentioned in the Cocoa documentations sometimes.
> 
> Is possible to do this here?

Unfortunately, no. That behavior is manually implemented by the framework 
authors.

Dave

> 
> I usually don't care about non-exhaustive enums. We avoid this even in 
> languages which do not enforce us (using external tools sometimes). But i can 
> understand the "need" in some projects.
> 
> 
> Em sáb, 30 de set de 2017 às 21:00, Slava Pestov via swift-evolution 
> mailto:swift-evolution@swift.org>> escreveu:
>> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I don’t see how it’s impractical. Quite a lot about how the library should 
>> be optimally compiled and used depends on what you plan to do with it. If 
>> it’s going to be installed somewhere private and you can guarantee clients 
>> will always have the latest version, you can assume all data types are 
>> final, @_fixed_layout, @exhaustive, whatever (essentially in-module). An 
>> example of that would be a library embedded inside an iOS app bundle. If 
>> it’s going to be installed somewhere public and expose some API (like 
>> Apple’s frameworks), then you’re going to have to think about binary 
>> compatibility.
>> 
>> That also means that in-app libraries are optimised as much as they can be, 
>> and that resilience-related changes on the declaration side can be limited 
>> to the limited set of Swift developers who truly have to care about that.
> 
> We do plan on exposing an -enable-resilience flag which basically does what 
> you describe. When a library is built without -enable-resilience, all types 
> are assumed to be fixed layout, etc. However, we don’t want language flags to 
> change language semantics, so exhaustive/nonexhaustive still make sense even 
> when building without resilience, I think. When you switch over a 
> non-exhaustive enum that came from a library built without 
> -enable-resilience, the compiler can still use the most efficient possible 
> access pattern and assume that no new cases will be introduced, but the type 
> checker would still require a default case to be present. The optimizer can 
> then basically strip out the default case as dead code.
> 
> Slava
> 
>> 
>> - Karl
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Enums and Source Compatibility

2017-10-02 Thread Wallacy via swift-evolution

@Slava

If my understanding is correct. If I compile my application with the x.y.z
version of a Apple System Framework (like Cocoa). And this framework is
updated, several calls from my application to the "new" framework version
x.z.a behave like in the x.y.z version for compatibility issues right? I
see this being mentioned in the Cocoa documentations sometimes.

Is possible to do this here?

I usually don't care about non-exhaustive enums. We avoid this even in
languages which do not enforce us (using external tools sometimes). But i
can understand the "need" in some projects.


Em sáb, 30 de set de 2017 às 21:00, Slava Pestov via swift-evolution <
swift-evolution@swift.org> escreveu:

> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don’t see how it’s impractical. Quite a lot about how the library should
> be optimally compiled and used depends on what you plan to do with it. If
> it’s going to be installed somewhere private and you can guarantee clients
> will always have the latest version, you can assume all data types are
> final, @_fixed_layout, @exhaustive, whatever (essentially in-module). An
> example of that would be a library embedded inside an iOS app bundle. If
> it’s going to be installed somewhere public and expose some API (like
> Apple’s frameworks), then you’re going to have to think about binary
> compatibility.
>
> That also means that in-app libraries are optimised as much as they can
> be, and that resilience-related changes on the declaration side can be
> limited to the limited set of Swift developers who truly have to care about
> that.
>
>
> We do plan on exposing an -enable-resilience flag which basically does
> what you describe. When a library is built without -enable-resilience, all
> types are assumed to be fixed layout, etc. However, we don’t want language
> flags to change language semantics, so exhaustive/nonexhaustive still make
> sense even when building without resilience, I think. When you switch over
> a non-exhaustive enum that came from a library built without
> -enable-resilience, the compiler can still use the most efficient possible
> access pattern and assume that no new cases will be introduced, but the
> type checker would still require a default case to be present. The
> optimizer can then basically strip out the default case as dead code.
>
> Slava
>
>
> - Karl
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

What is your use case for this?

On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi All.
>
> I’d like to help as well. I have fun with operators.
>
> There is also the issue of code security with invisible unicode characters
> and characters that look exactly alike.
>
>
> Unless there is a compelling reason to add them, I think we should ban
> invisible characters.  What is the harm of characters that look alike?
>
>
> Especially if people want to use the character in question as both an
> identifier and an operator: We can make the character an identifier and its
> lookalike an operator (or the other way around).
>
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

2017-10-02 Thread David Sweeris via swift-evolution


> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution 
>>  wrote:
>> 
>> Hi All.
>> 
>> I’d like to help as well. I have fun with operators.
>> 
>> There is also the issue of code security with invisible unicode characters 
>> and characters that look exactly alike.
> 
> Unless there is a compelling reason to add them, I think we should ban 
> invisible characters.  What is the harm of characters that look alike?

Especially if people want to use the character in question as both an 
identifier and an operator: We can make the character an identifier and its 
lookalike an operator (or the other way around).

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

Re: [swift-evolution] Enums and Source Compatibility

2017-10-02 Thread Charlie Monroe via swift-evolution

+1 for everything Vladimir says - which is why I'm pushing for switch! (just 
like try!, etc.) which would preserve current behavior.

> On Oct 2, 2017, at 5:25 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> 
> Sorry to bother, but I still can't understand how the proposed change 
> *without* a 'future' case in switch will change our life and what would be 
> our steps to support our code and to not make our code buggy.
> If I misunderstand something - sorry, please point me on this and I hope this 
> also help some one like me to understand the subject better.
> 
> For example. I use OAuth2 framework, built by Carthage. Did add the 
> OAuth2.framework to my project.
> 
> Currently OAuth2 exports 'public enum OAuth2Error'. I do have a place in my 
> code where I switch on each case of such error instance to do my best with 
> error: generate detailed description for user, other additional steps 
> depending on error.
> 
> Will/should author of OAuth2 make OAuth2Error 'exhaustive' ? No.
> Will new cases be added to that enum in future: Most likely Yes.
> Do I need to switch on each case in my code? Yes.
> Can I currently rely on compiler to keep my error processing in sync with 
> error cases defined in framework? Yes.
> Can new cases appear in *run-time* of my app: NO, framework in embedded.
> Will I be able to rely on compiler after the proposed change? No?!
> What should I do to keep my switch in sync with OAuth2Error cases after each 
> update of OAuth2 library(framework)? Manually check if new cases are added?! 
> Configure lint/other tools to help me with this?!
> 
> What I, as a developer, as a consumer of framework, need - is a way to 
> exhaustively switch on *some* external non-exhaustive enums *at the moment of 
> compilation*. And we can accomplish this only(AFAICT) with 'future' case in 
> 'switch'.
> In case we'll have 'future' case my life will not be *worse* for this project 
> : I'll add it to my switch and still can receive help from compiler to keep 
> switch exhaustive.
> 
> I don't support the opinion that we can't introduce 'future' case because of 
> we can't test it:
> 
> 1. Not being able to keep my switch exhaustive when I need this, and so not 
> being able to provide users of my app with best experience - IMO is worse.
> 2. In my particular example, 'future' case will be *never* called, if I 
> understand correctly.
> 3. If switch on non-exhaustive enum is exhaustive by fact, we can't test the 
> 'default' branch also. So, 'future' is in same position here with 'default'
> 4. I believe if we'll decide we need 'future' case - we can suggest a way to 
> call code in that case during the test process.
> 
> Seems like for embedded frameworks we should apply the same rules(regarding 
> enums) as for sources, as we compile the app with concrete binary of 
> framework and there just can't be new cases in enums. No?
> 
> Thank you for your time.
> Vladimir.
> 
> On 01.10.2017 3:00, Slava Pestov via swift-evolution wrote:
>>> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I don’t see how it’s impractical. Quite a lot about how the library should 
>>> be optimally compiled and used depends on what you plan to do with it. If 
>>> it’s going to be installed somewhere private and you can guarantee clients 
>>> will always have the latest version, you can assume all data types are 
>>> final, @_fixed_layout, @exhaustive, whatever (essentially in-module). An 
>>> example of that would be a library embedded inside an iOS app bundle. If 
>>> it’s going to be installed somewhere public and expose some API (like 
>>> Apple’s frameworks), then you’re going to have to think about binary 
>>> compatibility.
>>> 
>>> That also means that in-app libraries are optimised as much as they can be, 
>>> and that resilience-related changes on the declaration side can be limited 
>>> to the limited set of Swift developers who truly have to care about that.
>> We do plan on exposing an -enable-resilience flag which basically does what 
>> you describe. When a library is built without -enable-resilience, all types 
>> are assumed to be fixed layout, etc. However, we don’t want language flags 
>> to change language semantics, so exhaustive/nonexhaustive still make sense 
>> even when building without resilience, I think. When you switch over a 
>> non-exhaustive enum that came from a library built without 
>> -enable-resilience, the compiler can still use the most efficient possible 
>> access pattern and assume that no new cases will be introduced, but the type 
>> checker would still require a default case to be present. The optimizer can 
>> then basically strip out the default case as dead code.
>> Slava
>>> 
>>> - Karl
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___

Re: [swift-evolution] Enums and Source Compatibility



Sorry to bother, but I still can't understand how the proposed change *without* a 
'future' case in switch will change our life and what would be our steps to support 
our code and to not make our code buggy.
If I misunderstand something - sorry, please point me on this and I hope this also 
help some one like me to understand the subject better.


For example. I use OAuth2 framework, built by Carthage. Did add the OAuth2.framework 
to my project.


Currently OAuth2 exports 'public enum OAuth2Error'. I do have a place in my code 
where I switch on each case of such error instance to do my best with error: generate 
detailed description for user, other additional steps depending on error.


Will/should author of OAuth2 make OAuth2Error 'exhaustive' ? No.
Will new cases be added to that enum in future: Most likely Yes.
Do I need to switch on each case in my code? Yes.
Can I currently rely on compiler to keep my error processing in sync with error cases 
defined in framework? Yes.

Can new cases appear in *run-time* of my app: NO, framework in embedded.
Will I be able to rely on compiler after the proposed change? No?!
What should I do to keep my switch in sync with OAuth2Error cases after each update 
of OAuth2 library(framework)? Manually check if new cases are added?! Configure 
lint/other tools to help me with this?!


What I, as a developer, as a consumer of framework, need - is a way to exhaustively 
switch on *some* external non-exhaustive enums *at the moment of compilation*. And we 
can accomplish this only(AFAICT) with 'future' case in 'switch'.
In case we'll have 'future' case my life will not be *worse* for this project : I'll 
add it to my switch and still can receive help from compiler to keep switch exhaustive.


I don't support the opinion that we can't introduce 'future' case because of we can't 
test it:


1. Not being able to keep my switch exhaustive when I need this, and so not being 
able to provide users of my app with best experience - IMO is worse.
2. In my particular example, 'future' case will be *never* called, if I understand 
correctly.
3. If switch on non-exhaustive enum is exhaustive by fact, we can't test the 
'default' branch also. So, 'future' is in same position here with 'default'
4. I believe if we'll decide we need 'future' case - we can suggest a way to call 
code in that case during the test process.


Seems like for embedded frameworks we should apply the same rules(regarding enums) as 
for sources, as we compile the app with concrete binary of framework and there just 
can't be new cases in enums. No?


Thank you for your time.
Vladimir.

On 01.10.2017 3:00, Slava Pestov via swift-evolution wrote:


On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution 
mailto:swift-evolution@swift.org>> wrote:


I don’t see how it’s impractical. Quite a lot about how the library should be 
optimally compiled and used depends on what you plan to do with it. If it’s going 
to be installed somewhere private and you can guarantee clients will always have 
the latest version, you can assume all data types are final, @_fixed_layout, 
@exhaustive, whatever (essentially in-module). An example of that would be a 
library embedded inside an iOS app bundle. If it’s going to be installed somewhere 
public and expose some API (like Apple’s frameworks), then you’re going to have to 
think about binary compatibility.


That also means that in-app libraries are optimised as much as they can be, and 
that resilience-related changes on the declaration side can be limited to the 
limited set of Swift developers who truly have to care about that.


We do plan on exposing an -enable-resilience flag which basically does what you 
describe. When a library is built without -enable-resilience, all types are assumed 
to be fixed layout, etc. However, we don’t want language flags to change language 
semantics, so exhaustive/nonexhaustive still make sense even when building without 
resilience, I think. When you switch over a non-exhaustive enum that came from a 
library built without -enable-resilience, the compiler can still use the most 
efficient possible access pattern and assume that no new cases will be introduced, 
but the type checker would still require a default case to be present. The optimizer 
can then basically strip out the default case as dead code.


Slava



- Karl




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


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

Re: [swift-evolution] Re-pitch: remove(where:)

On 01.10.2017 22:44, Thorsten Seitz via swift-evolution wrote:
`formFilter` strongly implies that the result is a filter, so this would be a very 
bad choice. i do not follow the argument that it makes sense to just concatenate 
`form` and the non-mutating method name. The precedence set by `formUnion` is not a 
good one but at least there it makes sense because using union as a noun preserves 
the original meaning (the missing `with:` is tolerable) whereas `formFilter` conveys 
a completely wrong meaning.

FWIW Totally support Thorsten's opinion and replies to Ben's questions.

If we really also need mutating 'filter', why not 'formFiltered()'?
IMO this could be a valid name pattern for Swift in case simple noun like 'Filter' 
has no sense for what the method does: 'form' is a primary marker of mutating method, 
and 'Filtered' just clarifies what we'll have inside the instance in result of that 
call. Very similar to 'formUnion', but with correct meaning.

(Just thoughts... Isn't 'filterInPlace' the best variant ;-) )

I also don't think we need to fill the matrix, 2 filtering methods(one for 
non-mutating and one for mutating) IMO is a good minimum we need, and 'remove' is a 
right in-place filtering method with obvious meaning. If we'll need more filtering 
methods - we can add them later.

Vladimir.

To answer Ben's questions:

1. Is it right to assert that with a “removing” operation, the closure should 
return `true` for removal?

Yes, definitely.

2. Is it likely that users will want to switch from out-of- to in-place, and if 
so, will having to flip the closure cause confusion/bugs?

I do not think that it is very likely and if so I do not think that having to flip 
the closure will cause confusion because both methods are very differently named.

3. Should we “complete” the matrix of 4 operations, or is it fine for it to 
have gaps?

No, it is fine to have gaps. I would consider adding a `removing` variant but as 
there is no good name for the mutating variant of `filter` I would definitely not add 
this one.

4. If you are for completing, what should X and Y be called?

I am against completing.

-Thorsten

Am 27.09.2017 um 04:33 schrieb Xiaodi Wu via swift-evolution 
mailto:swift-evolution@swift.org>>:

On Tue, Sep 26, 2017 at 6:48 PM, Robert Bennett > wrote:

formFilter reads really weirdly... the use of filter in `filter` is not as a
noun, but as a verb — compare to e.g., formRemainder. Calling formFilter 
won’t
create a filter, it will “do” a filter. Perhaps formByFiltering?

That's interesting. I worry it might be too clever by half, though.

The prototypical "form" method is "formUnion"; it's so named because the term 
"union" is used in math as both noun and verb ("a union b"; "the union of a and b") 
and is a term of art that doesn't lend itself to the noun/verb rule in Swift. Here, 
"filter" is a term of art (otherwise, it'd be called "filtered"); now that "filter" 
is the non-mutating function (i.e., what should otherwise be a noun), there's no 
way to maintain the noun/verb rule in Swift. Therefore, without overthinking it, 
"formFilter".

Note that it's not "formUnion(with:)", just "formUnion(_:)". As is the case with 
"formUnion", no particular attempt is made here to turn this method name into an 
English phrase. The phrase "by filtering" very strongly suggests true-to-remove; 
that's the only way the term "filtering" is used in English. Here, we mean 
true-to-keep, and there's no way to express that with the English word "filter" 
between the receiver and the predicate with any sort of conjugation of the word or 
concise combination of helper words. The nearest good-English name might be 
something like "formFilteredResultKeeping(where:)", which is clearly awful for 
other reasons.

On Sep 26, 2017, at 7:23 PM, Xiaodi Wu via swift-evolution
mailto:swift-evolution@swift.org>> wrote:

On Tue, Sep 26, 2017 at 6:14 PM, Ben Cohen via swift-evolution
mailto:swift-evolution@swift.org>> wrote:

And here are my answers, in a separate email to maintain a shred of
separation between objectivity and subjectivity :)

> On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution 
mailto:swift-evolution@swift.org>> wrote:
>
> 1. Is it right to assert that with a “removing” operation, the 
closure should return `true` for removal?

Yes. If the closure returned false for removal a different, less 
readable,
name would be needed for the method.

Agree, yes.

> 2. Is it likely that users will want to switch from out-of- to 
in-place, and if so, will having to flip the closure cause confusion/bugs?

I don’t think so. While the argument for an in-place remove is partly 
that
it’s more efficient than x = x.filter (in addition to
reability/discoverability benefits), I think that once both an in- and
out-of-place version are av

swift-evolution@swift.org

2017-10-02 Thread Yun Zeng via swift-evolution

Thank u for ur reply Alex.
Sorry for the wrong topic. So I posted my problem on apple forums.
https://forums.developer.apple.com/message/266174#266174

Alex Blewitt 于2017年10月2日周一 下午6:24写道：

> This isn't an appropriate question for the swift-evolution list. You might
> like to ask it on one of the Apple developer forums at
> https://forums.developer.apple.com
>
> Alex
>
> On 2 Oct 2017, at 08:23, Yun Zeng via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi everyone,
> Recently I am developing Drag&Drop function on iPad and met a problem: I
> can not get Pages/Numbers/Keynote files from performDrop
> in UIDropInteractionDelegate. Here is my solution:
>
> 1. Create my own file item provider, follow the protocol
> NSItemProviderReading.
> 2. *override method readableTypeIdentifiersForItemProvider, register UTI
> of iWorks files which are com.apple.iwork.pages.sffpages,
> com.apple.iwork.numbers.sffnumbers and com.apple.keynote.key.* I got
> those UTI from [[NSWorkspace sharedWorkspace] typeOfFile:filePath error:
> nil]
> 3. override + (instancetype)objectWithItemProviderData:(NSData *)data
> typeIdentifier:(NSString *)typeIdentifier error:(NSError * _Nullable
> __autoreleasing *)outError
> 4. implement canHandleSession of UIDropInteractionDelegate and return [session
> canLoadObjectsOfClass:[DTFileItemProvider class]]
>
> I do the same thing on office files, and it work very well, I can get
> file's data in performDrop. But iWorks file are not.
>
> So did I set the wrong UTI or something?
> --
> Zeng Yun
> iOS Engineer
> Email/QQ: zengyun.program...@gmail.com
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> --
Zeng Yun
iOS Engineer
Email/QQ: zengyun.program...@gmail.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On 02.10.2017 8:30, Kenny Leung via swift-evolution wrote:
I guess theoretically you could have two variables that look alike, but are actually
different values, allowing you to insert some obfuscated malicious code somehow.

Also, IIRC, there is a "similar" problem exists with Right-To-Left "modifier", so
when inserted inside some variable name, you *see* (in browser/in editor) not the
same variable name that will be used *by compiler*. Can't find the link right now,
but if this could be helpful - will try to find.

Vladimir.

-Kenny

On Oct 1, 2017, at 10:01 PM, Chris Lattner > wrote:

On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution
mailto:swift-evolution@swift.org>> wrote:

Hi All.

I’d like to help as well. I have fun with operators.

There is also the issue of code security with invisible unicode characters and
characters that look exactly alike.

Unless there is a compelling reason to add them, I think we should ban invisible
characters. What is the harm of characters that look alike?

-Chris

(They should make a Coding font that ensures all characters look different.) Was
that ever resolved? Googling, I found this:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021446.html

Which seems to have been left at this:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/02.html

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160919/thread.html#27229

Should we throw all of this into the same pot, and make any characters that aren’t
on the approved list illegal?

-Kenny

On Sep 30, 2017, at 4:13 PM, Xiaodi Wu via swift-evolution
mailto:swift-evolution@swift.org>> wrote:

I’m happy to participate in the reshaping of the proposal. It would be nice to
gather a group of people again to help drive it forward.

That said, it’s unclear to me that superscript T is clearly an operator, any more
than would be superscript H (Hermitian), superscript 2, superscript 3, etc. But
at any rate, this would be discussion for the future workgroup.

I would strongly advocate that the things-that-are-identifiers group be strongly
tied to the existing, complete Unicode standard for such, and that the critical
parts of the previous document about normalization be retained.

On Sat, Sep 30, 2017 at 17:59 Chris Lattner via swift-evolution
mailto:swift-evolution@swift.org>> wrote:

The core team recently met to discuss PR609 - Refining identifier and
operator symbology:

https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/-refining-identifier-and-operator-symbology.md

The proposal correctly observes that the partitioning of unicode codepoints
into identifiers and operators is a mess in some cases. It really is an
outright bug for 🙂 to be an identifier, but ☹️ to be an operator. That
said, the proposal itself is complicated and is defined in terms of a bunch
of unicode classes that may evolve in the “wrong way for Swift” in the
future.

The core team would really like to get this sorted out for Swift 5, and
sooner is better than later :-). Because it seems that this is a really
hard
problem and that perfection is becoming the enemy of good
, the core team
requests the creation of a new proposal with a different approach. The
general observation is that there are three kinds of characters: things that
are obviously identifiers, things that are obviously math operators, and
things that are non-obvious. Things that are non-obvious can be made into
invalid code points, and legislated later in follow-up proposals if/when
someone cares to argue for them.

To make progress on this, we suggest a few separable steps:

First, please split out the changes to the ASCII characters (e.g. . and \
operator parsing rules) to its own (small) proposal, since it is unrelated
to
the unicode changes, and can make progress on that proposal independently.

Second, someone should take a look at the concrete set of unicode
identifiers
that are accepted by Swift 4 and write a new proposal that splits them into
the three groups: those that are clearly identifiers (which become
identifiers), those that are clearly operators (which become operators), and
those that are unclear or don’t matter (these become invalid code points).

I suggest that the criteria be based on*utility for Swift code*, not on the
underlying unicode classification. For example, the discussion thread for
PR609 mentions that the T character in “ xᵀ ” is defined in unicode as a
latin “letter”. Despite that, its use is Swift would clearly be as a
postfix
operator, so we should classify it as an operator.

Other suggestions:
- Math symbols are operators excepting those primarily used as identifiers

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

This is why I’m advocating for the sections of the previous draft that deal
with this issue to be maintained going forward. In that document and in the
links provided in that document, there are very extensive previous
discussions on lookalike characters and invisibles.

No need to rehash this very complex topic again. I will just say that are
languages for which invisible modifiers are essential, but there are
well-defined Unicode guidelines about restricting their use so as to
maximize security without impeding legitimate use cases. Lookalikes are
dealt with by Unicode in several flavors, and again the previous draft
discusses why a certain flavor of normalization is most appropriate for
Swift.
On Mon, Oct 2, 2017 at 03:13 Félix Cloutier via swift-evolution <
swift-evolution@swift.org> wrote:

> If you tried hard enough, you could probably create a variable that looks
> like it's shadowing one from an outer scope while it actually isn't, and
> use the two to confuse readers. This could trick people into thinking that
> some dangerous/backdoor code is actually good and safe, especially in the
> open-source world where you can't always trust your contributors.
>
> On one hand, other than the complexity of telling if two characters are
> lookalikes, I don't know why Αrray (GREEK CAPITAL LETTER ALPHA) and Array
> (LATIN CAPITAL LETTER A) should be considered different identifiers. On the
> other hand, I struggle to imagine the specifics of an exploit that uses
> that. You'd have to work pretty hard to assemble all the pieces of a
> backdoor in visually-similar variable names without arousing suspicion.
>
> Félix
>
>
> Le 1 oct. 2017 à 22:30, Kenny Leung via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I guess theoretically you could have two variables that look alike, but
> are actually different values, allowing you to insert some obfuscated
> malicious code somehow.
>
> -Kenny
>
>
> On Oct 1, 2017, at 10:01 PM, Chris Lattner  wrote:
>
>
> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi All.
>
> I’d like to help as well. I have fun with operators.
>
> There is also the issue of code security with invisible unicode characters
> and characters that look exactly alike.
>
>
> Unless there is a compelling reason to add them, I think we should ban
> invisible characters.  What is the harm of characters that look alike?
>
> -Chris
>
>
> (They should make a Coding font that ensures all characters look
> different.) Was that ever resolved? Googling, I found this:
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021446.html
>
> Which seems to have been left at this:
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/02.html
>
>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160919/thread.html#27229
>
> Should we throw all of this into the same pot, and make any characters
> that aren’t on the approved list illegal?
>
> -Kenny
>
>
> On Sep 30, 2017, at 4:13 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’m happy to participate in the reshaping of the proposal. It would be
> nice to gather a group of people again to help drive it forward.
>
> That said, it’s unclear to me that superscript T is clearly an operator,
> any more than would be superscript H (Hermitian), superscript 2,
> superscript 3, etc. But at any rate, this would be discussion for the
> future workgroup.
>
> I would strongly advocate that the things-that-are-identifiers group be
> strongly tied to the existing, complete Unicode standard for such, and that
> the critical parts of the previous document about normalization be retained.
>
> On Sat, Sep 30, 2017 at 17:59 Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> The core team recently met to discuss PR609 - Refining identifier and
>> operator symbology:
>>
>> https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/-refining-identifier-and-operator-symbology.md
>>
>> The proposal correctly observes that the partitioning of unicode
>> codepoints into identifiers and operators is a mess in some cases.  It
>> really is an outright bug for 🙂 to be an identifier, but ☹️ to be an
>> operator.  That said, the proposal itself is complicated and is defined in
>> terms of a bunch of unicode classes that may evolve in the “wrong way for
>> Swift” in the future.
>>
>> The core team would really like to get this sorted out for Swift 5, and
>> sooner is better than later :-).  Because it seems that this is a really
>> hard problem and that perfection is becoming the enemy of good
>> , the core
>> team requests the creation of a new proposal with a different approach.
>> The general observation is that there are three kinds of characters: things
>> that are obviously identifiers, things that are obviously mat

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

2017-10-02 Thread Karl Wagner via swift-evolution



> On 29. Sep 2017, at 02:59, Andrew Trick via swift-evolution 
>  wrote:
> 
> 
>> On Sep 6, 2017, at 10:15 PM, Taylor Swift > > wrote:
>> 
>> okay so I think so far what’s been agreed on is 
>> 
>> 1. rename “Bytes” to “Memory” in the raw pointer API. Note: this brings the 
>> `copyBytes(from:)` collection method into the scope of this proposal
>> 
>> 2. change raw offsets to be in terms of bytes, not typed strides. This 
>> argument will be called `atByteOffset:` and will only appear in 
>> UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in 
>> UnsafeMutableRawPointer, since we can just use pointer arithmetic now.
>> 
>> 
>> 3. move UnsafeMutableBufferPointer’s `at:` arguments to the front of the 
>> parameter list. mostly cause any pointer arithmetic happens in the front so 
>> structurally we want to mirror that.
>> 
>> 4. add dual (to:) single element initializers and assigners to 
>> UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s 
>> apparently not useful there. 
>> `UnsafeMutableRawPointer.initializeMemory(as:repeating:count:)` still 
>> loses its default count to prevent confusion with its buffer variant.
>> 
>> 5. memory deallocation on buffer pointers is clearly documented to only be 
>> defined behavior when the buffer matches a whole heap block. 
> 
> 
> Kelvin,
> 
> Attempting to limit the scope of this proposal backfired. I was hoping to 
> avoid discussing changes to the slice API, instead providing basic 
> functionality within the buffer API itself. However, Dave Abrahams has argued 
> that once the slice API is extended, the positional arguments are extraneous 
> and less clear.
> 
> Instead of
> 
>   buf.intialize(at: i, from: source)
> 
> We want to force a more obvious idiom:
> 
>   buf[i.. 
> I think this is a reasonable argument and convinced myself that it's possible 
> to extend the slice API. I'm also convinced now that we don't need overloads 
> to handle an UnsafeBufferPointer source, instead we can provide a single 
> generic entry point on both UnsafeMutableBufferPointer and its slice, 
> optimized within the implementation:
> 
>  `initialize(from: S) -> (S.Iterator, Index)
> 
> We can always drop down to the UnsafePointer API to get back to a direct 
> unsafe implementation as a temporary workaround for performance issues.
> 
> Let's set aside for now whether we support full or partial 
> initialization/assignment, how to handle moveInitialize, and whether we need 
> to return the Iterator/Index. This is going to require another iteration on 
> swift-evolution, which we should discuss in a separate thread. 
> 
> At this point, I suggest removing the controversial aspects of SE-0184 so 
> that we can put the other changes behind us and focus future discussion 
> around a smaller follow-up proposal.
> 
> Here I've summarized the changes that I think could be accepted as-is:
> https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e 
> 
> 
> If you amend SE-0184 accordingly and file a new PR, I think it can be quickly 
> approved.
> 
> -Andy
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

So I understand that partial deallocation was never really supported (even if 
the old API allowed you to write it) but, given that, would it be possible to 
add reallocation to re-size an already allocated buffer? That’s a pretty 
glaring hole in the Swift raw-memory API.

- Karl

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

Re: [swift-evolution] Idea: Public Access Modifier Respected in Type Definition