Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

[Thorsten Seitz via swift-evolution]

> Am 26.10.2016 um 18:41 schrieb Chris Lattner via swift-evolution 
> :
> 
>> On Oct 26, 2016, at 1:11 AM, alessandro aresta  
>> wrote:
>> Ensure is more comprehensible, guard is for sure "always" been there in 
>> older languages... could it be kind of aliased somehow? I tend to confuse 
>> guard sometimes, despite many few decades of using it.
> 
> No, we don’t introduce needless aliases for keywords like this.
> 
> I haven’t seen it mentioned on this thread yet, but we did consider “ensure” 
> back when the guard statement was being designed for Swift 2.  We 
> specifically avoided it because “ensure” is very much in the lexicon of pre 
> and post conditions, and we want to reserve its use if/when we ever get there.

Good point! Looking forward to that :-) 
I always liked Eiffel's handling of pre and post conditions.

-Thorsten 

> 
> -Chris
> ___
> 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] [External] Re: [Pitch] Replace the ternary operator with an in-language function

[Thorsten Seitz via swift-evolution]

+1 to Jon's answer.
-1 to the proposal. I have argued in the past for introducing an if-then-else 
expression instead of the ternary operator but I wouldn't replace it with a 
clunky function which reduces readability a lot IMHO.

-Thorsten 

> Am 26.10.2016 um 19:57 schrieb Jon Akhtar via swift-evolution 
> :
> 
> I think that we need to get past the “leftovers from C” being a bad thing 
> mindset. Familiar constructs make Swift easier for programmers (its target 
> audience) easier to learn.
> 
> Point by point:
> 
> Being a holdover from C isn’t a bad thing. We can take things that were 
> useful in C and make them part of Swift. Who said C language elements were a 
> non-goal of Swift. And to the “ternary operator is hard to learn” point. This 
> point gets made over and over in proposals to change Swift, ease of learning 
> is like performance and security – you can never have enough so there is no 
> counter-argument. If you can’t learn the ternary operator, Swift isn’t the 
> language for you, because what are you going to do when you get to generics 
> and higher order functions.
> If the ternary operator adds complexity to the compiler then it really isn’t 
> a holdover from C. We have quite a long time to know how to parse it from our 
> C legacy.
> See #1, new users are always confused about everything. They don’t stay that 
> way. The language doesn’t need to be tuned to support it’s non-users. Most 
> developers understand the ternary operator, and it is useful to them. Who is 
> this language for?
> The “:” appears in other places in the grammar. So what. So do parenthesis 
> and brackets. It is just a token used in a grammar rule as a separator, it 
> doesn’t have a meaning on its own, and it shouldn’t have one that isn’t its 
> function.
> So your argument is to make the ternary expression longer to discourage 
> nesting. This is much different than the argument for function(a++, ++a) 
> where order of function parameter evaluation influenced the code, but was not 
> expressed by it. Everything is fully expressed by the ternary operator 
> including order of evaluation.
> I see no problem with it being limited to bool. I don’t want Javascript’s “” 
> == false.
> What would be proposed (and has been) is the if expression which is more 
> verbose but easier to read
> Again, the C hate.
> You leave out the reason for those languages to leave out the ternary 
> operator. What was their rationale?
> I’m sorry you had a hard time with it. But you learned it, and now you can 
> apply that knowledge to any language that has it. To add to the anecdotal 
> evidence you provided, I did not have a hard time learning it.
> I can distill this down to “C is old and not modern so lets get rid of 
> anything from C” and “I had a hard time learning the ternary operator"
> 
> Bottom line, most developers know the ternary expression if they come from C, 
> C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different 
> for style reasons. We will be making a niche language, because what you learn 
> isn’t portable to another language like it is if you learn Java, then get a 
> job programming in C#.
> 
> 
> 
> From:  on behalf of Mark Sands via 
> swift-evolution 
> Reply-To: Mark Sands 
> Date: Wednesday, October 26, 2016 at 09:55
> To: William Sumner 
> Cc: Swift-Evolution 
> Subject: [External] Re: [swift-evolution] [Pitch] Replace the ternary 
> operator with an in-language function
> 
> 
> 
>> Training users to expect source-breaking churn would be highly damaging to 
>> the language. The removal of C-style for loops and increment/decrement 
>> operators came with sufficient justification beyond their being inherited 
>> from C. I don’t think there’s a sufficient justification for this change, 
>> especially with the bar set high for such changes. 
>> 
>> Preston
> 
> My apologies for skewing the conversation off-topic. I think what I meant to 
> imply is that we shouldn't be afraid of a deprecation warning. Migrating away 
> from a ternary operator is trivial, and the consequences usually come with 
> better readability.
> 
> Ignoring my statement about "leftovers from C" opposition, I do think there 
> is sufficient and very strong justification from the 10 items that Charlotte 
> has listed. I think it would be more valuable if one could pick apart each 
> bullet point they find excusable and list their reasons why it's not 
> compelling enough to warrant change.
> + V2 Checkin API
> + V2 Checkout API
> + V2 Get Admission Records [Updated]
> + V2 Get Scan Records
> - New SQLite Data File generation
> - V2 Get User Events
> - V2 Scan Record Submission
> 
> - GDO Ticket Purchase Integration API
> 
> - V2 Get Ticket Record(s) [New]
> - V2 Ticket Creation API [Updated]
> - V2 Ticket Info API [New]
> - V2 Ticket Transfer API [New]
> 

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

[David Sweeris via swift-evolution]

> On Oct 27, 2016, at 08:21, Jay Abbott  wrote:
> 
> You’re really in pun mode today, David! :)
> 
It's the best mode 

> But I do really like Marco’s suggestion of guard: because it changes the 
> interpretation…
> 
> guard: x > 0 else { return }
> This now reads as: This is a guard: x must be greater than zero, otherwise 
> return. The only issue is it has the same syntax as a break-label so becomes 
> potentially ambiguous/confusing. Is there another way that could be achieved?
> 
The ambiguity could be resolved by disallowing keywords as labels. I don't use 
them much, though, so I'm not sure how much that would affect readability.

- Dave Sweeris

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

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

[David Sweeris via swift-evolution]

> On Oct 27, 2016, at 08:09, Haravikk  wrote:
> 
> 
>> On 27 Oct 2016, at 13:31, David Sweeris via swift-evolution 
>>  wrote:
>> 
>> 
>> On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution 
>>  wrote:
>> 
 On Oct 26, 2016, at 1:11 AM, alessandro aresta  
 wrote:
 Ensure is more comprehensible, guard is for sure "always" been there in 
 older languages... could it be kind of aliased somehow?
>>> 
>>> No, we don’t introduce needless aliases for keywords like this.
>> 
>> What about allowing internal non-type aliases?
>> alias ensure = guard //can't be public
>> I know it's kinda encroaching on "macro" territory, but can't we already do 
>> simple text substitutions by importing a #define from C? Would allowing 
>> non-type aliases really be any different?
>> 
>> It'd address the concerns raised by I think nearly all of the "term-of-art" 
>> vs "term-of-English" proposals. Prohibiting aliases from being declared as 
>> `public` would guard the language's namespace, and ensure that it doesn't 
>> get polluted with every library author's favorite alternate spelling(s).
> 
> This would just risk more confusion I think when mixing and matching code 
> that uses one or the other.

You could make that argument about any code that "wraps" or duplicates 
stdlib/language behavior. That doesn't mean you shouldn't be able to use it. 
I'm not in front of my computer, so I can't double-check, but I'm pretty sure 
you can already put "#define ensure guard" in a C file and import it... This 
would just make the syntax nicer.

Come to think of it, that means this would be out of scope for phase 1.

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

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

[Jay Abbott via swift-evolution]

You’re really in pun mode today, David! :)

Even though I originally pitched this, I go along with the source-churn
arguments people have made[1], and the one about ensure potentially being
used for something else in the future. But I do really like Marco’s
suggestion of guard: because it changes the interpretation…

guard: x > 0 else { return }

This now reads as: *This is a guard: x must be greater than zero, otherwise
return*. The only issue is it has the same syntax as a break-label so
becomes potentially ambiguous/confusing. Is there another way that could be
achieved?

[1] For larger changes, but I think some of the arguments against breaking
changes are weak for smaller changes/refinements.
​

On Thu, 27 Oct 2016 at 13:31 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Oct 26, 2016, at 1:11 AM, alessandro aresta 
> wrote:
>
> Ensure is more comprehensible, guard is for sure "always" been there in
> older languages... could it be kind of aliased somehow?
>
>
> No, we don’t introduce needless aliases for keywords like this.
>
>
> What about allowing internal non-type aliases?
> alias ensure = guard //can't be public
> I know it's kinda encroaching on "macro" territory, but can't we already
> do simple text substitutions by importing a #define from C? Would allowing
> non-type aliases really be any different?
>
> It'd address the concerns raised by I think nearly all of the
> "term-of-art" vs "term-of-English" proposals. Prohibiting aliases from
> being declared as `public` would *guard* the language's namespace, and
> *ensure* that it doesn't get polluted with every library author's
> favorite alternate spelling(s).
>
> - 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] [Proposal] Refining Identifier and Operator Symbology

[David Sweeris via swift-evolution]

Sent from my iPhone
> On Oct 25, 2016, at 10:24, Joe Groff via swift-evolution 
>  wrote:
> 
>> Ok, but to clarify the requirement, *every* file would have to declare the 
>> operators it is using at the top of the file.  It isn’t enough for them to 
>> be declared in some file within the current module.  Not having this 
>> property breaks the ability to do a quick parse of a file without doing name 
>> lookup.
> 
> Yeah, that's a tradeoff. I think that requiring non-standard operator use to 
> be explicitly declared could be a good thing, though, since I don't think 
> that we can realistically expect users to learn or intuitively agree on what 
> glyphs are "operator" or "identifier", no matter what character set we design.
I could get behind having to explicitly import operators:
import CoolLib
import operators CoolLib
or
import CoolLib {types functions vars operators}
But having to re-declare every "non-standard" operator for every file really 
limits their usefulness, IMHO.

> As long as { } aren't in the operator character set, we should still be able 
> to skip function bodies without parsing, so operator use declarations could 
> still be order-independent at the top level of declarations. (Whether it's a 
> good idea to bury your import declarations in the middle of your other decls 
> is another story.)
Oh, is using {} as operators on the table? There's gotta be some interesting 
syntax someone could make with those...

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

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

[Haravikk via swift-evolution]

> On 27 Oct 2016, at 13:31, David Sweeris via swift-evolution 
>  wrote:
> 
> 
> On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution 
> > wrote:
> 
>> On Oct 26, 2016, at 1:11 AM, alessandro aresta > > wrote:
>>> Ensure is more comprehensible, guard is for sure "always" been there in 
>>> older languages... could it be kind of aliased somehow?
>> 
>> No, we don’t introduce needless aliases for keywords like this.
> 
> What about allowing internal non-type aliases?
> alias ensure = guard //can't be public
> I know it's kinda encroaching on "macro" territory, but can't we already do 
> simple text substitutions by importing a #define from C? Would allowing 
> non-type aliases really be any different?
> 
> It'd address the concerns raised by I think nearly all of the "term-of-art" 
> vs "term-of-English" proposals. Prohibiting aliases from being declared as 
> `public` would guard the language's namespace, and ensure that it doesn't get 
> polluted with every library author's favorite alternate spelling(s).

This would just risk more confusion I think when mixing and matching code that 
uses one or the other. Personally I think that guard is fine, while ensure 
reads a bit better I like that guard sounds more authoritative, which suits its 
requirement to return/break/continue.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] rename 'guard' to 'ensure'

[David Sweeris via swift-evolution]

> On Oct 26, 2016, at 11:41, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Oct 26, 2016, at 1:11 AM, alessandro aresta  
>> wrote:
>> Ensure is more comprehensible, guard is for sure "always" been there in 
>> older languages... could it be kind of aliased somehow?
> 
> No, we don’t introduce needless aliases for keywords like this.

What about allowing internal non-type aliases?
alias ensure = guard //can't be public
I know it's kinda encroaching on "macro" territory, but can't we already do 
simple text substitutions by importing a #define from C? Would allowing 
non-type aliases really be any different?

It'd address the concerns raised by I think nearly all of the "term-of-art" vs 
"term-of-English" proposals. Prohibiting aliases from being declared as 
`public` would guard the language's namespace, and ensure that it doesn't get 
polluted with every library author's favorite alternate spelling(s).

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

Re: [swift-evolution] [Pitch] Expanded type category constraints

[David Sweeris via swift-evolution]

> On Oct 26, 2016, at 20:56, Russ Bishop via swift-evolution 
>  wrote:
> 
> Do we already have a proposal for expanding constraints to support categories 
> beyond class? I am guessing this might have ABI stability concerns, or at 
> least library resilience concerns.
> 
> If so and no one else has tackled it I’m happy to write up a proposal. There 
> are only a couple that I know of:
> 
> valuetype
> Only struct and enum types would satisfy this constraint.
> 
> valuetype(pure)
> A struct or enum that contain no reference types at all. The only reason to 
> add this would be allowing certain optimizations, though the way existentials 
> work today I’m not sure if this is even possible because the calls to value 
> witnesses need to be emitted anyway.
> 
> functiontype
> A function type. This doesn’t have much use today but eventually we could 
> expand this to support reflecting the number and type of arguments, 
> dynamically invoking, etc.
I think "valuetype(pure)" would make a good starting point for some stuff. It 
depends on what exactly "pure" means and whether there are other adjectives we 
can use.

There are (at least potential) optimizations whose name and exact definition 
are unclear to me. For example, does "pure" also imply that equality can be 
checked just by comparing the bits? Because that would exclude, say, a 1's 
complement integer type because they inherently have two bit patterns for 0, 
even though such a type would meet the definitions of "pure" that usually get 
suggested.

The topic of supporting a "pure"  has come up a few times before, and it 
seems like they never go anywhere because of a) too many differing views on 
what "pure" actually means, and b) a reluctance to support additional 
adjectives ("reallypure", or whatever) to specify which definition of "pure" is 
intended.

I suspect that this is purely a language barrier issue... (See what I did 
there? Aw yeah... ) Does anyone know of an online resource that explains 
graduate/phd-level computer science terms which are still under active research?


> If there aren’t any ABI or resilience concerns then we can shelve it. I 
> created https://bugs.swift.org/browse/SR-3056 to track the idea in either 
> case.
I keep losing track of what exactly constitutes "ABI stability and resilience". 
I'm pretty sure someone posted some guidelines on the matter, but I forgot to 
bookmark it.

- Dave Sweeris, who swears he's really not trying to drag every thread off-topic___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[David Sweeris via swift-evolution]

Oh, yeah, sorry, didn't mean to get so far OT

Sent from my iPhone

> On Oct 27, 2016, at 05:20, Jay Abbott  wrote:
> 
> David,
> 
> You make some good points in favour of explicit support for user-defined 
> ternary operators. You're right that it's a bit clunky without. Probably a 
> discussion for another thread though, and additive so not for phase 1. But 
> perhaps worth a proposal for phase 2?
> 
>> On Thu, 27 Oct 2016 at 09:23 David Sweeris  wrote:
>> 
>>> On Oct 26, 2016, at 21:29, Jay Abbott  wrote:
>>> 
>>> David, you can use two binary operators (or overload the same one twice if 
>>> you want) to create syntax that behaves like a ternary operator.
>>> 
>> 
>> Oh I know, it's just kinda clunky and inefficient sometimes, if you need to 
>> wrap a value in a struct or something simply to avoid ambiguity or enforce 
>> the correct syntax. It's not quite the same thing a ternary operator, but at 
>> one point I'd added `|` as both pre and postfix operators to allow code like 
>> "let y = |x|". The left `|` had to return a `_PartialAbsValueOp` and the 
>> right one had to take the same to invalidate the "let y = |x" or "let y = 
>> x|" syntax, one of which would've otherwise worked (depending on which op 
>> actually called "abs()").
>> 
>> I should've been clearer that I was talking about support for "free form" 
>> operators in general, including ternary ops, so that we don't have to fake 
>> them by declaring some # of traditional pre/in/postfix operators which all 
>> then have to work together (possibly exclusively, depending on the desired 
>> syntax), and might have to pass wrapper types around solely to help explain 
>> your syntax to the compiler.
>> 
>> Thanks for pointing it out, though. That's an easy trick to forget about.
>> 
>> - Dave Sweeris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[Jay Abbott via swift-evolution]

David,

You make some good points in favour of explicit support for user-defined
ternary operators. You're right that it's a bit clunky without. Probably a
discussion for another thread though, and additive so not for phase 1. But
perhaps worth a proposal for phase 2?

On Thu, 27 Oct 2016 at 09:23 David Sweeris  wrote:

>
> On Oct 26, 2016, at 21:29, Jay Abbott  wrote:
>
> David, you can use two binary operators (or overload the same one twice if
> you want) to create syntax that behaves like a ternary operator.
>
> Oh I know, it's just kinda clunky and inefficient sometimes, if you need
> to wrap a value in a struct or something simply to avoid ambiguity or
> enforce the correct syntax. It's not quite the same thing a ternary
> operator, but at one point I'd added `|` as both pre and postfix operators
> to allow code like "let y = |x|". The left `|` had to return a
> `_PartialAbsValueOp` and the right one had to take the same to invalidate
> the "let y = |x" or "let y = x|" syntax, one of which would've otherwise
> worked (depending on which op actually called "abs()").
>
> I should've been clearer that I was talking about support for "free form"
> operators in general, including ternary ops, so that we don't have to fake
> them by declaring some # of traditional pre/in/postfix operators which all
> then have to work together (possibly exclusively, depending on the desired
> syntax), and might have to pass wrapper types around solely to help explain
> your syntax to the compiler.
>
> Thanks for pointing it out, though. That's an easy trick to forget about.
>
> - Dave Sweeris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

[David Sweeris via swift-evolution]

> On Oct 26, 2016, at 21:29, Jay Abbott  wrote:
> 
> David, you can use two binary operators (or overload the same one twice if 
> you want) to create syntax that behaves like a ternary operator.
> 
Oh I know, it's just kinda clunky and inefficient sometimes, if you need to 
wrap a value in a struct or something simply to avoid ambiguity or enforce the 
correct syntax. It's not quite the same thing a ternary operator, but at one 
point I'd added `|` as both pre and postfix operators to allow code like "let y 
= |x|". The left `|` had to return a `_PartialAbsValueOp` and the right one had 
to take the same to invalidate the "let y = |x" or "let y = x|" syntax, one of 
which would've otherwise worked (depending on which op actually called "abs()").

I should've been clearer that I was talking about support for "free form" 
operators in general, including ternary ops, so that we don't have to fake them 
by declaring some # of traditional pre/in/postfix operators which all then have 
to work together (possibly exclusively, depending on the desired syntax), and 
might have to pass wrapper types around solely to help explain your syntax to 
the compiler.

Thanks for pointing it out, though. That's an easy trick to forget about.

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