Re: [swift-evolution] In-line scope designators

[Ted F.A. van Gaalen via swift-evolution]

Before bringing this forward, I’ve tried brackets  { } as well 
for “my feature” but found this to be a bit awkward, 
confusing with real program { } blocks, 
also because it has nothing to do with blocks
(except for the class or struct body as limitation) 
rather its effect is sequential, line by line, 
within the class or struct body.
e.g:
  default scope here.
  private:
   source lines
   all declarations in lines following are private
   until another in-line scope designator is encountered.
  defalutscope:
  source lines
   public:
  source lines
end of class/ struct/ 

Thus, it acts more or less like a compiler directive… 
therefore, perhaps this would better: 

@private:
   source lines
@public:
   source lines
@defaultscope:  // returns to default scope 
  source lines.
  
?

TedvG

> On 20. Jun 2017, at 18:32, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> You can already effectively have these "regions" using extensions, with the 
>> exception of stored properties since they can't be placed there.
> I still think nested extensions would have been a good addition to the 
> language: If we had those, 
> 
> struct MyType {
>   private {
>   var myPrivateVar: Int?
>   var anotherOne: String?
>   }
> }
> 
> would be a rather small piece of syntactic sugar...

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

Re: [swift-evolution] In-line scope designators

[Ted F.A. van Gaalen via swift-evolution]

Hi Tony

Personally, I find my solution much better because everything 
of a class struct definition stays together in one place,
instead of being scattered over multiple extensions, wich btw, 
can be placed anywhere, that is, not necessarily within 
the same source file.. (no doubt that is  what some people are 
going to do…  Also, Imho, this is not the right purpose of extensions. 
Extension are primary meant for users of classes/structs,  clearly, 
as the name implies, to extend these, while keeping the original 
class/structs intact and hidden from those users, if desired. 
So I’d would consider this being a bad bad programming practice, sorry. 
Btw. I’d prefer subclassing instead of extensions, however
this is not possible with structs... 

Costs? Of, course there are implications, but that is the consequence 
with every change to a programming language, with all the aspects 
you have described below. 
However, this is not a source changing feature, which should be not so 
difficult to implement, completely optional, and almost trivial to use also for 
starters.

TedvG

> On 20. Jun 2017, at 18:06, Tony Allevato <tony.allev...@gmail.com> wrote:
> 
> 
> 
> On Tue, Jun 20, 2017 at 8:57 AM Ted F.A. van Gaalen <tedvgios...@gmail.com 
> <mailto:tedvgios...@gmail.com>> wrote:
> Hi Tony 
> I don’t think so, then I would have to split my class up into extensions, 
> not really workable I’d say.
> 
> Why not?
> 
> What makes this workable:
> 
btw, internal: can be omitted here: 
> struct MyType {
>   internal:
> var
> var
> var
>   public:
> func
> func
>   private:
> func
> func
> }
> 
> but this not workable?
> 
> struct MyType {
>   var
>   var
>   var
> }
> public extension MyType {
>   func
>   func
> }
> private extension MyType {
>   func
>   func
> }
> 
> I don't see what's so bad about the latter example. It's just a different 
> syntax for what you're asking to do, except that it's already in the language.
> 
>  
> it would be an optional feature anyway. so one can still build classes
> like it is now, no problem. 
> I would like in-line scope designators *within* extensions as well.
> 
> Every optional feature proposed to be added to the language has costs 
> associated with it—design time, implementation time, cognitive load on people 
> learning the language—so what I'm trying to determine is benefits this would 
> add to justify that cost. Since this can effectively be achieved today with 
> extensions (again, with the exception of stored properties, which should be 
> fixed separately and then that exception goes away), I'm curious about what 
> you think is missing here.
> 
>  
> Regards
> TedvG.
> 
> more below inline
> 
>> On 20. Jun 2017, at 17:10, Tony Allevato <tony.allev...@gmail.com 
>> <mailto:tony.allev...@gmail.com>> wrote:
>> 
>> You can already effectively have these "regions" using extensions, with the 
>> exception of stored properties since they can't be placed there.
>> 
>> struct MyType { ... }
>> public extension MyType { ... }
>> private extension MyType { ... }
>> 
>> Once stored properties are allowed in extensions (IIRC supporting that 
>> within the same file as the type declaration is something the core team has 
>> said is reasonable?), you could do this there as well. Is this not 
>> sufficient for what you want to do?
>> 
>> Since there are already two ways of specifying the visibility of a type 
>> member (preceding the type itself, or using the default visibility of the 
>> declaring extension), I'd be wary of adding a third.
>> 
>> On Mon, Jun 19, 2017 at 10:57 PM Rien via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> I don’t like this, it violates the locality principle. I.e. that all 
>> information that is needed to understand something is close by.
> 
>  well, what then if you use parts of your program defined in other 
> sources, protocols … etc. ?  
> met vriendelijke groeten
> TedvG
> 
>> 
>> But since it is not something that everybody has to use… I don’t object to 
>> it either.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl <http://balancingrock.nl/>
>> Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/>
>> Github: http://github.com/Balancingrock <http://github.com/Balancingrock>
>> Project: http://swiftfire.nl <http://swiftfire.nl/> - An HTTP(S) web server 
>> framework in Swift
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>

Re: [swift-evolution] In-line scope designators

[Ted F.A. van Gaalen via swift-evolution]

Hi Tony 
I don’t think so, then I would have to split my class up into extensions, 
not really workable I’d say. it would be an optional feature anyway. so one can 
still build classes
like it is now, no problem. 
I would like in-line scope designators *within* extensions as well.
Regards
TedvG.

more below inline

> On 20. Jun 2017, at 17:10, Tony Allevato <tony.allev...@gmail.com> wrote:
> 
> You can already effectively have these "regions" using extensions, with the 
> exception of stored properties since they can't be placed there.
> 
> struct MyType { ... }
> public extension MyType { ... }
> private extension MyType { ... }
> 
> Once stored properties are allowed in extensions (IIRC supporting that within 
> the same file as the type declaration is something the core team has said is 
> reasonable?), you could do this there as well. Is this not sufficient for 
> what you want to do?
> 
> Since there are already two ways of specifying the visibility of a type 
> member (preceding the type itself, or using the default visibility of the 
> declaring extension), I'd be wary of adding a third.
> 
> On Mon, Jun 19, 2017 at 10:57 PM Rien via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> I don’t like this, it violates the locality principle. I.e. that all 
> information that is needed to understand something is close by.
 well, what then if you use parts of your program defined in other sources, 
protocols … etc. ?  
met vriendelijke groeten
TedvG
> 
> But since it is not something that everybody has to use… I don’t object to it 
> either.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl <http://balancingrock.nl/>
> Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/>
> Github: http://github.com/Balancingrock <http://github.com/Balancingrock>
> Project: http://swiftfire.nl <http://swiftfire.nl/> - An HTTP(S) web server 
> framework in Swift
> 
> 
> 
> 
> 
> 
> 
> > On 17 Jun 2017, at 23:48, Ted F.A. van Gaalen via swift-evolution 
> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >
> > (I am not sure if I should tag this subject with [pitch]? )
> >
> > Please don’t worry , I am not attempting to start a new
> > and infinite thread about whether or not the way scope
> > is handled in Swift is imho correct or not.
> > Errhm well, apart from that “protected” is missing,
> > but please let us not start again.. :o)
> >
> > No, it is more or less a convenience solution to
> > prevent unnecessary wear and tear to the following keys
> > on my keyboard: [ A,E, I, P,  R, T, V]
> >
> > I prefer it, not to expose those class or struct members
> > which should not be accessible outside the class or struct
> >
> > Currently, to prevent access to private Items,
> > I have to type the word “private” too many times:
> >
> > class  House
> > {
> > private var rooms = 5
> >   private var roofTiles = 11201
> >   private let paint =   UIColor.Blue;
> > private var yearTax: Money = “323,56"
> > private let garageVolume = 60.0
> >
> > init(..) {.. }
> >
> >  private func calculateTax() {...}
> >
> >  public func roomsUnoccupied() -> Int {…}
> >
> > func roofData(……) {…}
> >
> >  private func  a{…}
> > }
> >
> > To set the scope of a list of members I suggest the
> > “in-line scope modifiers”  (anyone with a better name for it?)
> >
> > For example if one has a source line containing the word
> > “private:” then all the following member declarations will
> > be “private” until another inline scope modifier is encountered
> > with one “default scope” to escape from it. like in the following example”
> >
> > The compiler can detect that it is an inline scope modifier, because it 
> > ends with a colon
> >
> > “Normal” scope modifiers, that is the ones which precede the member’s name
> > directly should imho not be allowed within such a scope block.
> > unless they would override for that specific item, but that looks ugly.
> >
> > getter & setters and init should appear in default scope
> > (or with no in-line scope modifiers)
> >
> > Inline scope modifiers can be specified as often as
> > desired and in arbitrary sequence.
> >
> >
> > class  House
> > {
> >  init(..) {.. }
> > private:// <——  In-line 
> > scope modif

Re: [swift-evolution] floating point numbers implicit conversion

[Ted F.A. van Gaalen via swift-evolution]

@Stephen @John: 
Interesting to learn about the low-level things, thank you,
but efficient or not. somewhere along the way, 
conversions are simply unavoidable, 
whether explicit or implicit, 
regardless of its performance...

Theoretically, doing:
aDouble = Double(aFloat) 
 should have the same performance as
aDouble = aFloat   //implicitly
The compiler simply generates the same code in both cases, i assume.

Implicit or explicit?  Thinking further, it seems to me that it doesn’t
matter because the programmer should be equally aware of the 
operation, whether it is an explicit or an implicit conversion.

(seems to be not so difficult assisted by verbose compiler warnings during 
editing) 

So, thinking along this line, (that is, the programmer has to make 
almost the same judging effort in both cases anyway) it seems 
logically correct that explicit conversions  are in fact superfluous, 
pointless, 
and can thus be removed from the language, with possibly the exception for 
explicit conversion functions that have extra parameters to influence
the conversion, like its precision, magnitude, rounding etc.
e.g: 
   anInt = Int(aFloat, truncation: .roundingUp) 

?

TedvG 


> On 20. Jun 2017, at 00:08, Stephen Canon <sca...@apple.com> wrote:
> 
>> 
>> On Jun 19, 2017, at 5:43 PM, David Sweeris <daveswee...@mac.com 
>> <mailto:daveswee...@mac.com>> wrote:
>> 
>> Sent from my iPhone
>> On Jun 19, 2017, at 13:44, John McCall via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>>> On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> var result: Float = 0.0
>>>>> result = float * integer * uint8 +  double   
>>>>> // here, all operands should be implicitly promoted to Double before the 
>>>>> complete expression evaluation.
>>>> 
>>>> You would have this produce different results than:
>>>> 
>>>>let temp = float * integer * uint8
>>>>result = temp + double
>>>> 
>>>> That would be extremely surprising to many unsuspecting users.
>>>> 
>>>> Don’t get me wrong; I *really want* implicit promotions (I proposed one 
>>>> scheme for them  way back when Swift was first unveiled publicly).
>>> 
>>> I don't!  At least not for floating point.  It is important for both 
>>> reliable behavior and performance that programmers understand and minimize 
>>> the conversions they do between different floating-point types.
>> 
>> How expensive is it?
> 
> On most contemporary hardware, it’s comparable to a floating-point add or 
> multiply. On current generation Intel, it’s actually a little bit more 
> expensive than that. Not catastrophic, but expensive enough that you are 
> throwing away half or more of your performance if you incur spurious 
> conversions on every operation.
> 
> This is really common in C and C++ where a naked floating-point literal like 
> 1.2 is double:
> 
>   float x;
>   x *= 1.2;
> 
> Instead of a bare multiplication (current generation x86 hardware: 1 µop and 
> 4 cycles latency) this produces a convert-to-double, multiplication, and 
> convert-to-float (5 µops and 14 cycles latency per Agner Fog).
> 
> –Steve

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

Re: [swift-evolution] In-line scope designators

[Ted F.A. van Gaalen via swift-evolution]

Hi Robert,

This would be an optional feature, can be left out. 
if one doesn’t use it nothing changes.
Although imho it looks better, the primary intent
is to hide/protect  members, be it vars, functions,
from outside access, without having to type scope
qualifiers on most of my source lines.
As you can see, personally I use vertical space a lot:
brackets on new lines, empty lines, etc.
I use a Mac Mini with a a 4K screen and a relative small font
(and reading glasses :o) thus having to scroll very little.

Kind Regards
TedvG

 
 
> On 19. Jun 2017, at 20:45, Robert Bennett <rltbenn...@icloud.com> wrote:
> 
> +1 for member variables, -1 for member functions. Functions take up too much 
> vertical space to make this convenient; you’d constantly be scrolling around 
> to view or modify the access level of a function. Plus I tend to group 
> functions by use — private functions go directly above the public function 
> that calls them. But member declarations are often one or just a few lines, 
> and additionally are often grouped by access level anyway (at least that’s 
> how I do it) so this provides a compact way to group them.
> 
> 
>> On Jun 17, 2017, at 5:48 PM, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> (I am not sure if I should tag this subject with [pitch]? ) 
>> 
>> Please don’t worry , I am not attempting to start a new
>> and infinite thread about whether or not the way scope
>> is handled in Swift is imho correct or not.
>> Errhm well, apart from that “protected” is missing,
>> but please let us not start again.. :o) 
>> 
>> No, it is more or less a convenience solution to
>> prevent unnecessary wear and tear to the following keys
>> on my keyboard: [ A,E, I, P,  R, T, V]
>> 
>> I prefer it, not to expose those class or struct members
>> which should not be accessible outside the class or struct
>> 
>> Currently, to prevent access to private Items,
>> I have to type the word “private” too many times:
>> 
>> class  House
>> {
>>private var rooms = 5
>>  private var roofTiles = 11201
>>  private let paint =   UIColor.Blue;
>>private var yearTax: Money = “323,56"
>>private let garageVolume = 60.0
>> 
>>init(..) {.. }
>> 
>> private func calculateTax() {...}
>> 
>> public func roomsUnoccupied() -> Int {…}
>> 
>>func roofData(……) {…}
>> 
>> private func  a{…} 
>> }
>> 
>> To set the scope of a list of members I suggest the
>> “in-line scope modifiers”  (anyone with a better name for it?) 
>> 
>> For example if one has a source line containing the word
>> “private:” then all the following member declarations will
>> be “private” until another inline scope modifier is encountered
>> with one “default scope” to escape from it. like in the following example”
>> 
>> The compiler can detect that it is an inline scope modifier, because it ends 
>> with a colon
>> 
>> “Normal” scope modifiers, that is the ones which precede the member’s name 
>> directly should imho not be allowed within such a scope block.
>> unless they would override for that specific item, but that looks ugly. 
>> 
>> getter & setters and init should appear in default scope
>> (or with no in-line scope modifiers)
>> 
>> Inline scope modifiers can be specified as often as
>> desired and in arbitrary sequence. 
>> 
>> 
>> class  House
>> {
>> init(..) {.. }
>>private:// <——  In-line scope 
>> modifier all following declarations are private here.
>>var rooms = 5
>>  var roofTiles = 11201
>>  let paint =   UIColor.Blue;
>>var yearTax: Money = “323,56"
>>func calculateTax() {…}
>>func  a{…} 
>> 
>>  public: // <——  In-line 
>> scope modifier
>> var garageVolume = 60.0  
>> func roomsUnoccupied() -> Int {…}
>> func roofData(……) {…}
>> 
>>  defaultscope: // <—— Return to default 
>> scope (only needed when preceding inline scope modifiers are present. )
>> 
>>  func sellHouse(buyer: CustomerID)   
>> }
>> 
>> See? looks a lot better, don’t you think so?  
>> it also makes sources more readable because one can 
>> now conveniently group items.
>> 
>> 100% source compatible with whatever scope 
>> mechanism now or in the future is or will be deployed.
>> 
>> 
>> (The idea is not exactly new, a similar construct is available in Object 
>> Pascal.)  
>> 
>> ?
>> 
>> Kind Regards
>> TedvG
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] floating point numbers implicit conversion

[Ted F.A. van Gaalen via swift-evolution]

if it were possible, I would only use one floating point type 
in my app, however FP conversions are needed often, 
because of heavy usage of library functions
e.g. SceneKit  that all work with different floating point types..
Programmers should be aware of the implications of conversions
e.g. learn and test these in playground if not completely understood...
TedvG
> On 19. Jun 2017, at 22:44, John McCall <rjmcc...@apple.com> wrote:
> 
>> On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> var result: Float = 0.0
>>> result = float * integer * uint8 +  double   
>>> // here, all operands should be implicitly promoted to Double before the 
>>> complete expression evaluation.
>> 
>> You would have this produce different results than:
>> 
>>  let temp = float * integer * uint8
>>  result = temp + double
>> 
>> That would be extremely surprising to many unsuspecting users.
>> 
>> Don’t get me wrong; I *really want* implicit promotions (I proposed one 
>> scheme for them  way back when Swift was first unveiled publicly).
> 
> I don't!  At least not for floating point.  It is important for both reliable 
> behavior and performance that programmers understand and minimize the 
> conversions they do between different floating-point types.
> 
> John.

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

Re: [swift-evolution] floating point numbers implicit conversion

[Ted F.A. van Gaalen via swift-evolution]

> On 19. Jun 2017, at 19:58, Stephen Canon <sca...@apple.com> wrote:
> 
>> On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> var result: Float = 0.0
>> result = float * integer * uint8 +  double   
>> // here, all operands should be implicitly promoted to Double before the 
>> complete expression evaluation.
> 
> You would have this produce different results than:
> 
>   let temp = float * integer * uint8
“temp”  is now a Float
>   result = temp + double
“temp" being implicitly converted to a Double before expression evaluation 
> 
(assuming the var “result” is still the Float declared in my example)
after conversion, the expression would be implicitly, type wise  
float = Float( double + double)

Apart perhaps from small floating point inherent imprecision, I don’t see much 
difference...
am I missing something? 

> That would be extremely surprising to many unsuspecting users.
> 
> Don’t get me wrong; I *really want* implicit promotions (I proposed one 
> scheme for them  way back when Swift was first unveiled publicly). But 
> there’s a lot more subtlety around them than it seems (for example the C and 
> C++ implicit promotion rules can easily be described on a half-sheet of 
> paper, but are the source of *innumerable* bugs). I would rather have no 
> implicit promotions than half-baked implicit promotions.
> 
I C what you mean. yes, implicit conversion can produce unexpected results, yes.
Have to be used either with common sense or a lot of debugging or both :o)
But that’s the case with many programming language features...
(no debuggers in ca 1980, IDEs are pure luxury :o)

TedvG 

> – Steve

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

[swift-evolution] In-line scope designators

[Ted F.A. van Gaalen via swift-evolution]

(I am not sure if I should tag this subject with [pitch]? ) 

Please don’t worry , I am not attempting to start a new
and infinite thread about whether or not the way scope
is handled in Swift is imho correct or not.
Errhm well, apart from that “protected” is missing,
but please let us not start again.. :o) 

No, it is more or less a convenience solution to
prevent unnecessary wear and tear to the following keys
on my keyboard: [ A,E, I, P,  R, T, V]

I prefer it, not to expose those class or struct members
which should not be accessible outside the class or struct

Currently, to prevent access to private Items,
I have to type the word “private” too many times:

class  House
{
private var rooms = 5
private var roofTiles = 11201
private let paint =   UIColor.Blue;
private var yearTax: Money = “323,56"
private let garageVolume = 60.0

init(..) {.. }

 private func calculateTax() {...}

 public func roomsUnoccupied() -> Int {…}

func roofData(……) {…}

 private func  a{…} 
}

To set the scope of a list of members I suggest the
“in-line scope modifiers”  (anyone with a better name for it?) 

For example if one has a source line containing the word
“private:” then all the following member declarations will
be “private” until another inline scope modifier is encountered
with one “default scope” to escape from it. like in the following example”

The compiler can detect that it is an inline scope modifier, because it ends 
with a colon

“Normal” scope modifiers, that is the ones which precede the member’s name 
directly should imho not be allowed within such a scope block.
unless they would override for that specific item, but that looks ugly. 

getter & setters and init should appear in default scope
(or with no in-line scope modifiers)

Inline scope modifiers can be specified as often as
desired and in arbitrary sequence. 


class  House
{
   init(..) {.. }
private:// <——  In-line scope 
modifier all following declarations are private here.
var rooms = 5
var roofTiles = 11201
let paint =   UIColor.Blue;
var yearTax: Money = “323,56"
func calculateTax() {…}
func  a{…} 

  public: // <——  In-line scope 
modifier
 var garageVolume = 60.0  
 func roomsUnoccupied() -> Int {…}
 func roofData(……) {…}

  defaultscope: // <—— Return to default 
scope (only needed when preceding inline scope modifiers are present. )
 
  func sellHouse(buyer: CustomerID)   
}

See? looks a lot better, don’t you think so?  
it also makes sources more readable because one can 
now conveniently group items.

100% source compatible with whatever scope 
mechanism now or in the future is or will be deployed.


(The idea is not exactly new, a similar construct is available in Object 
Pascal.)  

?

Kind Regards
TedvG






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

Re: [swift-evolution] floating point numbers implicit conversion

[Ted F.A. van Gaalen via swift-evolution]

Hi Xiaodi 

in 1966-1970 PL/I, a static-typed procedural block-structured programming 
language
far ahead of its time,  with the purpose of giving "all things to all 
programmers” 
was introduced by IBM as their main (mainframe) programming flagship.

I’ve worked with PL/I very often during my life. It is truly general purpose 
and has tons 
of features and is because of that quite overwhelming for starters like me in 
1976 after 
Fortran as my first PL.  PL/I  is a bit like riding a gigantic powerful motor 
cycle without 
much instruction from the start and without training wheels back then of 
course. 
Took some time to master PL/I (no screens let alone IDEs back then), however, 
with 
the great reward to be in control of one of the most powerful PLs on the planet.

You might ask, what’s  the context of this somewhat nostalgic emission:   :o) 

PL/I also has many data types like Binary, Bit, Character Complex, Decimal
Fixed, Float,Picture etc. of various lengths and storage
.
Implicit data type conversion (coercion) between almost all PL/I data types has 
been available in PL/I right from the start. No problem - that is if you know 
what you are doing.
What exactly to expect from conversions in PL/I is always predictable, also
because it is described in detail in the programming manuals.
Furthermore PL/I diagnostics and warnings are excellent. 

So, implicit data type conversion (coercion) has been successfully implemented 
and used in an 
already complex programming language (in some cases far more advanced as Swift 
- apart from
OOP) almost 40 years ago… 
It is now 2017 and you’re telling me that coercion is too difficult to 
implement in Swift ?? 

> On 16. Jun 2017, at 18:19, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> Implicit promotion has been brought up on the list before, many times over 
> many years. The scale and implications of the change not to be underestimated.
> 
It should be not so difficult I think… as it simply replaces
explicit casts and the compiler can detect implicit conversions easily; 
be it in assignments, with expression operands or as call parameters.  

> To give a taste of what would be involved, consider that new integer 
> protocols were recently implemented that allow heterogeneous comparison; 
> these have proved to be tricky to implement in a way that preserves user 
> expectations in the context of integer literals. (I will write shortly with 
> thoughts on revisiting certain specifics.)
Yes, can’t react on this need more information, I don’t see this in context of 
“user expectations” either.

btw, I was merely discussing Floating Point conversion <=>  Integers? 


> Implicit promotion would be much more complicated.
Why do you think so? 
float = double  // compiler inferred type conversion, what’s so difficult about 
this assignment?
Currently  you’d have to use  
float = Float(double)  // and you’re doing (explicitly) exactly the same thing. 


> There is little point in discussing whether such a feature in the abstract is 
> desirable or not.
Abstract? I don’t think so and have described this subject fairly concrete, 
illustrated with some examples. 
To me and certainly also many others this feature is desirable.
As your say yourself
“it has been brought forward so many times” 
Obviously many desire this feature and find this important.

> It would be necessary to have a detailed proposed design and evaluate whether 
> the specific design is desirable, in light of its interactions with other 
> parts of the system.
after gathering more insight, yes. 

> For one, I think it’s important that no code that is currently legal produce 
> a different result: this in itself is not trivial to achieve.
As you know, Swift currently does not facilitate implicit conversion (coercion),
which implies that current code (which of course does not contain implicit 
conversions) 
will function exactly as it does now, when it was compiled in a Swift version 
in which
implicit conversion were implemented. 

Kind Regards,
TedvG
www.tedvg.com





> On Fri, Jun 16, 2017 at 11:08 Ted F.A. van Gaalen via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hello,
> 
> Appr. a year ago I suggested to allow implicit conversion between floating 
> point number types,
> that is between Float, CGFloat  Double..Float80 … 
> (Note that CGFloat IS a Double on 64-bit systems btw),
> 
> E.g I am currently making things using SceneKit 3D, wich obviously involves a 
> lot
> of floating point arithmetic, using functions from several libraries where
> some use Floats, others Double or CGFloat etc.. 
> That wouldn't be so bad, were it not that all the work that I do contains
> a lot of of unavoidable explicit Floating point conversions like so:
> 
> let ypos = CGFloat(1080.0 - (yGravity * yfactor))  // double in expression to 
> 

Re: [swift-evolution] floating point numbers implicit conversion

[Ted F.A. van Gaalen via swift-evolution]

> On 18. Jun 2017, at 08:04, Xiaodi Wu  wrote:
> 
> On Sun, Jun 18, 2017 at 00:02 Brent Royal-Gordon  > wrote:
>> On Jun 17, 2017, at 8:43 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> How do you express the idea that, when you add values of disparate types T 
>> and U, the result should be of the type with greater precision? You need to 
>> be able to spell this somehow.
> 
> 
> To be slightly less coy:
> 
> :)

what if one would allow all numeric conversions, 
also to those with smaller storage, and from signed to unsigned,
(Of course with clear compiler warnings) 
but trap (throwable) conversion errors at runtime? 
Runtime errors would then be things like: 
-assigning a negative value to an unsigned integer
-assigning a too large integer to an integer  e.g   UInt8 = 43234
E.g. doing this:

let n1 = 255   // inferred Int
var u1:UInt8
u1 = n1  //this would be OK because:  0 <=n1 <= 255 
(currently this is not possible in Swift: "cannot assign value of type ‘Int’ to 
type ‘UInt8’)  

Personally, I’d prefer that this should be allowed and cause a runtime error 
when conversion is not possible.
Compile time warning could be “Warning: Overflow might occur when assigning 
value from type ‘Int’ to type ‘UInt8’”  
Same for floats if out of magnitude.

Then this would not be necessary:
> 
> You need to be able to say that one value type is a subtype of another. Then 
> you can say Int8 is a subtype of Int16, and the compiler knows that it can 
> convert any Int8 to an Int16 but not vice versa. This adds lots of complexity 
> and makes parts of the compiler that are currently far too slow even slower, 
> but it's not difficult to imagine, just difficult to practically implement 
> given the current state of the Swift compiler.
> 
> And then there are follow-on issues. As but a single example, consider 
> integer literals, which are of course commonly used with these operations. 
> Take the following statements:
> 
> var x = 42 as UInt32
> let y = x + 2
> 
> What is the inferred type of 2? Currently, that would be UInt32. What is the 
> inferred type of y? That would also be UInt32. So, it's tempting to say, 
> let's keep this rule that integer literals are inferred to be of the same 
> type. But now:
> 
> let z = x + (-2)
> 
> What is the inferred type of -2? If it's UInt32, then this expression is a 
> compile-time error and we've ruled out integer promotion for a common use 
> case. If OTOH it's the default IntegerLiteralType (Int), what is the type of 
> z? It would have to be Int.

One of the things imho which I would change in Swift: 
I’d prefer this rule:
*** within the scope of an expression, individual operands (vars and literals) 
  should all implicitly be promoted to lowest possible precision
 with which the complete expression can be evaluated  *** 
ergo:
 the smallest-type rule as it is now should be replaced by the above rule
or in other words
  the smallest type possible within the scope of the complete expression. 

Your above example would then not result in a compilation error.  (currently it 
does) 

in your example, with this rule, x would be implicitly promoted to Int 
and the result *z* would be an inferred Int.
 
another example of wat could be an allowable expression: 

var result: Float = 0.0
result = float * integer * uint8 +  double   
// here, all operands should be implicitly promoted to Double before the 
complete expression evaluation.

//the evaluation of the expression results in a Double, which then is converted 
to a float during assignment to “result” 

To summarise: Allow implicit conversions, but trap impossible things at runtime,
unless of course the compiler can already figure out that it doesn’t work e.g 
in some cases with literals: 
let n1 = 234543
var u1:UInt8 = n1   // overflow error

   

> 
> Now suppose x were instead of type UInt64. What would be the type of z, if -2 
> is inferred to be of type Int? The answer would have to be 
> DoubleWidth. That is clearly overkill for subtracting 2. So let's say 
> instead that the literal is inferred to be of the smallest type that can 
> represent the value (i.e. Int8). If so, then what is the result of this 
> computation?
> 
> let a = x / ~0
> 
> Currently, in Swift 3, ~0 is equal to UInt32.max. But if we have a rule that 
> the literal should be inferred to be the smallest type that can represent the 
> value, then the result of this computation _changes_. That won't do. So let's 
> say instead that the literal is inferred to be of the same type as the other 
> operand, unless it is not representable as such, in which case it is then of 
> the smallest type that can represent the value. Firstly, and critically, this 
> is not very easy to reason about. Secondly, it still does not solve another 
> problem with the smallest-type rule. 

[swift-evolution] floating point numbers implicit conversion

[Ted F.A. van Gaalen via swift-evolution]

Hello,

Appr. a year ago I suggested to allow implicit conversion between floating 
point number types,
that is between Float, CGFloat  Double..Float80 … 
(Note that CGFloat IS a Double on 64-bit systems btw),

E.g I am currently making things using SceneKit 3D, wich obviously involves a 
lot
of floating point arithmetic, using functions from several libraries where
some use Floats, others Double or CGFloat etc.. 
That wouldn't be so bad, were it not that all the work that I do contains
a lot of of unavoidable explicit Floating point conversions like so:

let ypos = CGFloat(1080.0 - (yGravity * yfactor))  // double in expression to 
CGFloat

camera1.reorientate (
SCNVector3(x: Float(motionGravityY *  -0.08),
   y: Float(motionGravityX *  -0.1),
   z: roll ) )

This is tedious and makes source less readable.

With implicit floating point number conversion It could be like this

var float1,float2,float3: Float
var double1,double2,double3: Double
var cgfloat1, cgfloat2, ccgfloat3 CGFloat 

float1 = cgfloat2 * double3 + float1   // implicit conversion should be allowed 
(whereby everything 
in the expression should be promoted to the highest precision var in the 
expression (Double here)  
which then would be type wise:   
Float = CGFloat(implicitly. promoted to Double) * Double) + Float  (imp. 
promoted to Double) 

Also, implicit conversion when passing function parameters would be very 
convenient as well e.g.

This function: 
   func someMath(p1: Float, p2: Float, result: Inout Float) {…}

could then be called without explicit conversion like so:

someMath(p1: double1, p2: cgfloat1,  result: )   

// yes, also on inout parameters. This is done 2 times during the call and when 
returning.
 

As I vaguely remember  there were objections to this implicit conversion of FP 
numbers,
because this was (as viewed back then) too complicated to implement?

Note that people that regularly work with floating point numbers are
well aware about having a precision loss when e.g.  when converting
from Double to Float, or indeed between other numerical types as well 
no problem.

For those not desiring such flexibility, there could be a new compiler option(s)
that disallows this freedom of implicit floating point number conversion.

or have at least (suppressible) compiler warnings about precision loss,
e.g when doing this: float = double.. 

?

Kind Regards from Speyer, Germany
TedvG









  



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

Re: [swift-evolution] Enhancing access levels without breaking changes

[Ted F.A. van Gaalen via swift-evolution]

Hi,

(wrote a bit or two about this before)
For a moment, let's make the unlikely assumption that really no one has a 
problem 
with changing the next Swift version, having lexical scope as the only scope 
mechanism. . . 
which would be that each and every item is visible and accessible only inside 
the source level where it is declared,
unless of course revealed outwards with an access modifier. 
(.e.g. protected, internal, public (private would be implicit))  
Like it is in most other procedural/OOP languages.

Now, also assume that Swift has always been that way: lexical scope only.

Given this, as yet, hypothetical Swift environment, my questions are: 
Would this be feasible in Swift? 

E.g. does it constrain/conflict with current Swift language 
constructs/organisation ? 
(you can reveal items to the outside scope with access modifiers)

Side effects, technical limitations?

Am I right in thinking that Swift would be a lot easier to work with if lexical 
scope had
been there from the very beginning?

If Swift 4 would be set to lexical scope only, could the source conversion be 
automated successfully?
 E.g. by automatically adding the "internal" access modifier to all items that 
don't have an access modifier right now in Swift 3.x ? 

If all this would be possible, it would of course be a very drastic change, 
but what is it worth to finally get scope access right once and for all ?  
(imho)

The necessity of “private” or “fileprivate” keywords is by itself
a clear signal that the current access mechanism is wrong, I think. 

Very interested in your opinion, thank you.
Anyone?


TedvG
www.tedvg.com




> 
> Date: Wed, 12 Apr 2017 07:30:04 +0200
> From: David Hart >
> To: Chris Lattner >
> Cc: swift-evolution  >
> Subject: Re: [swift-evolution] Enhancing access levels without
>   breakingchanges
> Message-ID:  >
> Content-Type: text/plain; charset=utf-8
> 
> 
> On 12 Apr 2017, at 07:16, Chris Lattner  > wrote:
> 
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution 
> > wrote:
>> 
 I understand what you are saying and I wouldn't be against relaxing that 
 requirement (not talking for Chris here).
 
 The model would change from "Types share scopes with their extensions in 
 the same file the type was defined" to "Types and their extensions share 
 the same scope in each file".
>>> 
>>> Oh, I had missed that somehow.  I agree that that is a very strange rule.  
>>> Do you know why it was proposed that way?
>> 
>> We had to take a stance and Chris seemed to prefer the rule that was 
>> proposed. I didn't press because I'm sure he has reasons for preferring it 
>> that way. But I have a preference for generalizing visibility to all 
>> extensions, even to those in a different file than the type.
> 
> To me, the reason for limiting it to a file is about predictability, the 
> ability to locally reason about a type, and the need to define some boundary 
> (for symbol visibility reasons).  Saying that extensions to a type have 
> access to private members if they are in the same module is just as arbitrary 
> as limiting it to a single file, and a whole lot less useful from the 
> “reasoning about a type” perspective.
> 
> I think you misunderstand. We were talking about two extensions of a type, in 
> a different file from the type, to share private members between themselves.
> Doug Gregor mentioned it during the PR process and we added an example to 
> disallow it, but in hindsight, I think it should be allowed.
> Expanding it beyond a module would require a ton of stuff to be exported that 
> otherwise wouldn’t be, and would defeat a ton of optimization potential that 
> we can’t accept.
> 
> -Chris
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Type-based ‘private’ access within a file

[Ted F.A. van Gaalen via swift-evolution]

Dear Colleague Travellers In Turbulent And Interesting Digital Times :) 

Sorry, that I have not read all other opinions on this thread thoroughly,
there's so much of it which confuses me. The sheer volume of this traffic gives 
me the impression that scope management is Swift is fundamentally wrong.  

As written before on another thread, namely that currently all members of a 
class or struct are exposed by default, due to having a default scope of  
‘internal’  and are therefore accessible in the entire module is imho very bad 
and unstructured programming practice.  (e.g. why are the members of a function 
(correctly) have private scope and classes and struct don't have this? Isn't 
that very inconsistent? 

In Swift there should be lexical scope only, I think,  as in most procedural / 
OOP programming languages.  This is a very simple and above all consistent 
rule, easy to understand for everyone, even rookies, and also would make 
programming in Swift more consistent and reliable. (Maybe it would even 
simplify the compiler processing more or less, but I have not enough knowledge 
about this.)

Having consistent lexical scope only, with no exceptions, would in almost all 
cases eliminate the necessity to explicitly use the keywords “private” and 
“fileprivate”. . . The latter imho is really awkward, solid proof of the 
inconsistency with current Swift scoping, because the scope of what's in a file 
is treated differently that that of other coding scopes, like class, struct, 
function or any other {} block... isn't it? 

So I'd prefer consistent lexical scope only, that is, unless overruled by a 
scope modifier, an item should be available only within the code level/unit 
where it is declared.

However, I assume that it is too late to correct this, as it would turn the 
existing code base of all Swift users completely upside down, wouldn't it?
making it necessary for the ones supporting this to flee to another universe to 
avoid repercussions... the very idea...

Kind Regards
TedvG
www.tedvg.com



> Date: Wed, 5 Apr 2017 20:34:27 -0500
> From: Matthew Johnson >
> To: Colin Barrett  >
> Cc: swift-evolution  >
> Subject: Re: [swift-evolution] Type-based ‘private’ access within
>   a file
> Message-ID:  >
> Content-Type: text/plain; charset="utf-8"
> 
> 
>> On Apr 5, 2017, at 7:11 PM, Colin Barrett via swift-evolution 
>> > wrote:
>> 
>> I'm broadly in favor of this.
>> 
>> On Mon, Apr 3, 2017 at 2:35 PM Douglas Gregor via swift-evolution 
>> > > >> wrote:
>> Hello Swift Community,
>> 
>> In rejecting SE-0159 
>> >  
>> >,
>>  the core team described a potential direction we would like to investigate 
>> for “private” access control that admits a limited form of type-based access 
>> control within files. The core team is seeking some discussion here and a 
>> motivated volunteer to put together a proposal along these lines for review 
>> in the Swift 4 time-frame (i.e., very soon). To be clear, the core team it’s 
>> sure this is the right direction to go… but it appears promising and we 
>> would *love* to be able to settle the access-control issue.
>> 
>> The design, specifically, is that a “private” member declared within a type 
>> “X” or an extension thereof would be accessible from:
>> 
>>  * An extension of “X” in the same file
>>  * The definition of “X”, if it occurs in the same file
>>  * A nested type (or extension thereof) of one of the above that occurs 
>> in the same file
>> 
>> This design has a number of apparent benefits:
>>  + “private” becomes the right default for “less than whole module” 
>> visibility, and aligns well with Swift coding style that divides a type’s 
>> definition into a number of extensions.
>>  + “fileprivate” remains for existing use cases, but now it’s use it 
>> more rare, which has several advantages:
>>  + It fits well with the "progressive disclosure” philosophy 
>> behind Swift: you can use public/internal/private for a while before 
>> encountering and having to learn about “fileprivate”   (note: we thought 
>> this was going to be true of SE-0025 
>> >  
>> >,

Re: [swift-evolution] Make class and struct members private by default / Type-Based access

[Ted F.A. van Gaalen via swift-evolution]

Hi David

jikes! You’re right, total blunder. I should do my homework better :o) 
I have been using Java before, be it with the assumption that it had private 
scope
for class members, because of the line of PLs I was using before I started 
using Java
I went on programming assuming that it had, which never led to scope conflicts 
because
of programming consequently within this assumption, so, I never noticed this. 
:o) 
 
This is because in most PLs in my historyFortran -> Cobol-> PL/1 -> Pascal 
-> Modula ->
C -> C++ consistent lexical scope is present (since ca. 1960 with Algol)   
After that C# (nice language too, which has it)  and ObjC (which hasn’t) and 
Smalltalk for many years
which has (needs) no scope modifiers at all (in a class all methods are not 
private
but variables are.) 

Sorry for the incorrect assumptions. 
Nevertheless I hold on to my point of view that there should be lexical scope 
only in Swift,
(as Swift being a procedural/OOP language) 
however rigidly enforcing this in Swift 4 would be probably too much of a 
change now.

I do not understand what is so hard on private-by-default? (that is, if used
this way right from the beginning of writing an application, 
(provided a program language is set up that way)

TedvG
www.tedvg.com
> On 4. Apr 2017, at 22:17, David Waite <da...@alkaline-solutions.com> wrote:
> 
> 
>> On Apr 4, 2017, at 7:07 AM, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi Xiaodi,
>> 
>> that currently all members of a class or struct are exposed by default by 
>> having
>> a default scope of  ‘internal’  and are therefore accessible in the entire 
>> module
>> is imho very bad unstructured programming practice. 
>> 
>> In no other OOP language it is implemented
>> that way.. 
> 
> I think you may be forgetting Java (and Ruby, and Python, and Go, and 
> Objective-C, and…)
> 
> In my experience , the hard-private-by-default comes from C++ and heavily 
> influenced languages like C# and Rust.
> 
> -DW

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

Re: [swift-evolution] Make class and struct members private by default / Type-Based access

[Ted F.A. van Gaalen via swift-evolution]

Hi Xiaodi,

that currently all members of a class or struct are exposed by default by having
a default scope of  ‘internal’  and are therefore accessible in the entire 
module
is imho very bad unstructured programming practice. 

In no other OOP language it is implemented
that way.. 

from this Swift blog:
https://developer.apple.com/swift/blog/?id=5 
<https://developer.apple.com/swift/blog/?id=5>

i quote from this blog:

"By default, all entities have  internal access. 
This allows application developers to largely ignore access control, 
and most Swift code already written will continue to work without change."

Whoever wrote this, imho it is bad: especially this part:
"This allows application developers to largely ignore access control”

To say the least, this not really a very well thought over sentence, 
which appears to me something like: 
“Hey yeah, it’s ok, just start coding like a blind horse, 
don’t worry about the details now. Care about it later. ” 

This is certainly not my idea of what is described as “Progressive Disclosure” 
and encourages bad and unstructured programming. Students learn
undesirable habits which, as with any habit, are hard to get rid off and
can carry on throughout a large part of their career. 

So, in this perspective, what is related to “Progressive Disclosure” should
be viewed with a grain of salt and due to the complexity of Swift its relevancy
is limited and should be approached with caution. 

True, in Swift , one can write in a very simple way, but this apparent 
triviality is 
deceiving... To make professional applications with Swift (or for that 
matter in any other serious  programming language ) one should only
start making real apps equipped with a thorough understanding of the overall
language structure, its philosophy and environment, rather  sooner than later.

That ’s exactly where tutorials, courses, books, playgrounds etc. are meant for!
There is a lot of very good material available, so there is really no obstacle
to learn these fundamentals of the Swift language quite well before embarking 
on creating professional Swift apps. 

Of course, one cannot (should not) define anything at all without knowing 
about scope, access modifiers!  Luckily, compared to other aspects of PLs, 
understanding scope of variables is almost trivial. Provided of course that
the scope mechanism is natural and orthogonal, unfortunately this is 
not the case in Swift,.

Also in Swift there should be lexical scope only, I think,  as in almost any 
other
procedural / OOP programming language. Swift is one of them.
This also eliminates the necessity of the keywords “private” and “fileprivate”
and makes the scope context easy to conceive , especially for
beginning programmers.   


But it seems to be too late now to correct this deficiency (imho) in Swift I 
guess..

Concerning your *struct* example:
with correct lexical scope, it should then be written like this: 

struct PointOfView
{
public let x: Int // or any other applicable access modifier 
 public let y: Int

public func distanceToPoint( p: PointOfView) -> Double{. . .} 

let pr: Int   // private by default, not available 
outside this struct.  
func Foo() { . . .}  //  private function   
}

As written before, for a class, one can add
‘protected’  items like so:

 protected var foo:Double   // available to descendants (subclasses)

Kind Regards from a sunny www.speyer.de
TedvG
www.tedvg.com 



> On 4. Apr 2017, at 01:44, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> The default access level is internal by default, not public. While there are 
> good reasons to not make members public by default, it is important that 
> members are internal by default.
> 
> One important reason: progressive disclosure. Access modifiers make sense 
> after you understand what encapsulation is all about. Encapsulation only 
> really makes sense after you can actually write a type. If members are 
> private by default, you cannot write a useful type without also learning 
> access modifiers!
> 
> Put another way:
> 
> struct Point {
> let x: Int
> let y: Int
> }
> 
> ...is by itself a useful type. If x and y were private, then this type would 
> do nothing. Users would have to learn about access modifiers before they can 
> write a useful type.
> On Mon, Apr 3, 2017 at 18:13 Ted F.A. van Gaalen via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hello, 
> 
> (this is related to: Type-based ‘private’ access within a file)
> 
> Currently class and struct items  (variables, functions..) are public by 
> default
> that is,  always accessible outside the class’s scope
> for example:  (Swift 3.1) 
> 
> class AsItIsNow
> {
> pr

[swift-evolution] Make class and struct members private by default / Type-Based access

[Ted F.A. van Gaalen via swift-evolution]

Hello, 

(this is related to: Type-based ‘private’ access within a file)

Currently class and struct items  (variables, functions..) are public by default
that is,  always accessible outside the class’s scope
for example:  (Swift 3.1) 

class AsItIsNow
{
private var a = 10
private var b = 12

func aPlusB() -> Int
{
   return a + b
}

private func helperFunction()
{
   . . . 
}
}

Having all items public by default has the following disadvantages:

   • All members are exposed by default, wether intended or not. This
  could lead to class misusage unintended by the class’s creator. 

   • To prevent undesired access of functions vars etc. inside a class
  one has to prefix often too many items with the ‘private’ access modifier 
keyword.
  Most of the functionality  and items inside a class or struct are meant 
to 
  be used internally  and should  not be revealed to the outside world. 

   • It does not comply (contradicts)  with lexical scope as in Swift functions 
etc. 
  
   • It is frontally different to most other programming languages and
 therefore confusing for those coming from C#, C++, Java, Pascal etc. 

I experience this as fundamentally wrong. 

Imho it should be as in the next example, everything in a class
is private by default. To access/deploy items from outside they 
need to be defined with the ‘public’ access modifier, 
not the other way around, please. 

class AsItShouldBeImho
{
   var a = 10  // private by default
var b = 12   // also

public func aPlusB() -> Int
{
   return a + b
}

func privateFunction()   
{
   . . . 
}
}

‘public’  could be an inferred attribute
for items defined with getters and setters.. 
or the compiler would demand public
for getters and setters..

The ‘protected’ keyword is needed. 
‘protected’ would mean that the items are
accessible in subclasses   (class only)  

private items would also be inaccessible in
class extensions. 

It is as yet unclear to me why it has not been done
like so from the beginning of Swift…

I’ve been lost in the eternal discussions over private access modifiers,
the volume of it makes me think that (either way in this discussions) the whole
scope definition is wrong in Swift .
especially using a file as scope limiter. 
Imho there should be lexical scope only.
as in most other programming languages.
If done so correctly , one wouldn’t even need the ‘private’ keyword...

Kind Regards
TedvG

www.tedvg.com 
www.ravelnotes.com







 

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

et
{
return TGString( Array(ar[r]) )
}
set(newValue)
{
ar[r] = ArraySlice(newValue.ar)
}
}

func right( _ len: Int) -> TGString
{
var l = len

if l > count
{
l = count
}
return TGString(Array(ar[count - l..<count]))
}

func left(_ len: Int) -> TGString
{
var l = len

if l > count
{
l = count
}
return TGString(Array(ar[0..<l]))
}

func mid(_ pos: Int, _ len: Int) -> TGString
{
if pos >= count
{
return TGString.empty()
}

var l = len

if l > pos + len
{
l = pos + len
}
return TGString(Array(ar[pos.. TGString
{
if pos >= count
{
return TGString.empty()
}

return TGString(Array(ar[pos..<count]))
}

mutating func insert(at: Int, string: TGString)
{
ar.insert(contentsOf: string.ar, at: at)
}

// Concatenate
static func + (left: TGString, right: TGString) -> TGString
{
return(TGString(left.ar + right.ar) )
}

// Return an empty TGString:
static func empty() -> TGString
{
return TGString([Character]())
}
} // end TGString

// trivial isn’t? but effective... 
var strabc = "abcdefghjiklmnopqrstuvwxyz"
var strABC = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
var abc = TGString(strabc)
var ABC = TGString(strABC)

func test()
{
// as in Basic: left$, mid$, right$
print(abc.left(5))
print(abc.mid(5,10))
print(ABC.mid(5))
print(ABC.right(5))
// ranges and concatenation:
print(abc[12..<23])
print(abc.left(5) + ABC.mid(6,6) + abc[10...25])

// eat anything:
let d:Double = -3.14159
print(TGString(d))
 
let n:Int = 1234
print(TGString(n))

print(TGString(1234.56789))

let str = abc[15..<17].asString  // Copy to to normal Swift String
print(str)

let s = "\(abc[12..<20])" // interpolate to normal Swift String.
print(s)

abc[3..<5] = TGString("34") // if lenghts don't match:
abc[8...9] = ABC[24...25]   //  length of dest. string is altered.
abc[12] = TGString("")  //  if src l > 1 will insert remainder after 
dest.12 here
abc[14] = TGString("")  //  empty removes character at pos.
print(abc)
abc.insert(at: 3, string: ABC[0..<3])
print(abc)
}
 
test()
 
outputs this: 
abcde
fghjiklmno
FGHIJKLMNOPQRSTUVWXYZ
VWXYZ
mnopqrstuvw
abcdeGHIJKLklmnopqrstuvwxyz
-3.14159
1234
1234.56789
pq
mnopqrst
abc34fghYZkl$$$nopqrstuvwxyz
abcABC34fghYZkl$$$nopqrstuvwxyz

> 
> Thats not to say that there aren’t features which would simplify/clarify 
> algorithms working in this manner.
> 
true. 
This discussion was interesting, triggers further thinking, 
maybe even more because it touched more principal considerations

As you know, of course, a programming language is always a compromise between 
human
and computer “The Machine” so to speak. It started years ago with writing
Assembler then came higher PLs like Fortran, PL/1 Cobol etc. later C and C++
to just name a few… Also we see deviations in directions like OOP FP.. 
(and everybody thinks they’re right of course even me :o)

What (even in this time (2017))  often seems to be an unavoidable obstacle
is the tradeoff/compromise speed/distance-from-the machine, that is,
how far optimisation aspects are emerging/surfacing through all these 
layers of abstraction into the upper levels of the programming language... 

In this view, the essence of this discussion was perhaps then not the 
triviality 
wether or not one should instantiate a character array or not, but rather that 
obviously (not only) in Swift these underlying optimisation aspects more or
less form a undesired restriction… ? 

TedvG.
1980 - from Yes song: "Machine Messiah" - read the lyrics also: very much in 
context here!  

> -DW
> 
>> On Feb 24, 2017, at 4:27 PM, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> ok, I understand, thank you
>> TedvG
>>> On 25 Feb 2017, at 00:25, David Sweeris <daveswee...@mac.com 
>>> <mailto:daveswee...@mac.com>> wrote:
>>> 
>>> 
>>>> On Feb 24, 2017, at 13:41, Ted F.A. van Gaalen <tedvgios...@gmail.com 
>>>> <mailto:tedvgios...@gmail.com>> wrote:
>>>> 
>>>> Hi David & Dave
>>>> 
>>>> can you explain that in more detail?
>>>>>> Wouldn’t that turn simple character access into a mutating function?
>>>> 
>>>> assigning li

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

ok, I understand, thank you
TedvG
> On 25 Feb 2017, at 00:25, David Sweeris  wrote:
> 
> 
>> On Feb 24, 2017, at 13:41, Ted F.A. van Gaalen  wrote:
>> 
>> Hi David & Dave
>> 
>> can you explain that in more detail?
 Wouldn’t that turn simple character access into a mutating function?
>> 
>> assigning like   s[11…14] = str  is of course, yes.
>> only then - that is if the character array thus has been changed - 
>> it has to update the string in storage, yes. 
>> 
>> but  str = s[n..> so you’d have to maintain keep (private) a isChanged: Bool or bit.
>> a checksum over the character array .  
>> ?
> 
> It mutates because the String has to instantiate the Array to 
> which you're indexing into, if it doesn't already exist. It may not make any 
> externally visible changes, but it's still a change.
> 
> - Dave Sweeris

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hi Dave
Thanks for your time to go in to this an explain.
This optimising goes much further then I thought.

> That's fine. Please don't be offended that I don't wish to argue it further. 
> It's been an interesting exercise while I'm on vacation and I hoped it would 
> lay out some general principles that would be useful to others in future even 
> if you are not convinced, but when I get back to work next week I'll have to 
> focus on other things.

yes, I understand, it would become too iterative and time consuming I guess. 
( how can you become work-detached if you keep doing things like this during 
vacation? )  

Enjoy your vacation!  
TedvG




> On 24 Feb 2017, at 22:40, Dave Abrahams  wrote:
> 
> 
> 
> Sent from my moss-covered three-handled family gradunza
> 
> On Feb 23, 2017, at 2:04 PM, Ted F.A. van Gaalen  > wrote:
> 
>> 
>>> On 23 Feb 2017, at 02:24, Dave Abrahams >> > wrote:
>>> 
>>> Equally a non-starter. All known threadsafe schemes that require caches to 
>>> be updated upon non-mutating operations have horrible performance issues, 
>>> and further this would penalize all string code by reserving space for the 
>>> cache and filling it even for the vast majority of operations that don't 
>>> require random access.
>> Well, maybe “caching” is not the right description for what I've suggested.
>> It is more like:
>>   let all strings be stored as they are now, but as soon as you want to work 
>> with 
>> random accessing parts of a string just “lift the string out of normal 
>> optimised string storage” 
>>  and then add (temporarily)  a Character array so one can work with this 
>> array directly ” 
> 
> That's a cache.
> 
>> which implies that all other strings remain as they are.  ergo: efficiency 
>> is only reduced for the “elevated” strings,
> 
> You have to add that temporary array somewhere.  The performance of every 
> string is penalized for that storage, and also for the cost of throwing it 
> out upon mutation. Every branch counts. 
> 
>> Using e.g. str.freeSpace(), if necessary, would then place the String back 
>> in its normal storage domain, thereby disposing the Character array
>> associated with it. 
> 
> Avoiding hidden dynamic storage overhead that needs to be freed is an 
> explicit goal of the design (see the section on String and Substring).
> 
>>> Trust me, we've gotten lots of such suggestions and thought through the 
>>> implications of each one very carefully.  
>> That’s good, because it means, that a lot of people are interested in this 
>> subject and wish to help.  
>> Of course you’ll get many of suggestions that might not be very useful, 
>> perhaps like this one... but sometimes suddenly someone 
>> comes along with things that might never have occurred to you. 
>> That is the beautiful nature of ideas…
> 
> But at some point, I hope you'll understand, I also have to say that I think 
> all the simple schemes have been adequately explored and the complex ones all 
> seem to have this basic property of relying on caches, which has unacceptable 
> performance, complexity, and, yes, usability costs. Analyzing and refuting 
> each one in detail begins to be a waste of time after that.  I'm not really 
> willing to go further down this road unless someone has an implementation and 
> experimental evidence that demonstrates it as non-problematic. 
> 
> 
>>> I'm afraid you will have to accept being disappointed about this. 
>> Well, like most developers, I am a stubborn kind of guy.. 
>> Luckily Swift is very flexible like Lego, so I rolled my own convenience 
>> struct.
>> If I need direct access on a string I simply copy the string to it.
>> it permits things like this:  (and growing) 
>> 
>> let strabc = "abcdefghjiklmnopqrstuvwxyz"
>> let strABC = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
>> var abc = TGString(strabc)
>> var ABC = TGString(strABC)
>> 
>> func test()
>> {
>> // as in Basic: left$, mid$, right$
>> print(abc.left(5))
>> print(abc.mid(5,10))
>> print(ABC.mid(5))
>> print(ABC.right(5))
>> 
>> // ranges and concatenation:
>> print(abc[12..<23])
>> print(abc.left(5) + ABC.mid(6,6) + abc[10...25])
>> 
>> // eat anything:
>> let d:Double = -3.14159
>> print(TGString(d))
>>  
>> let n:Int = 1234
>> print(TGString(n))
>> 
>> print(TGString(1234.56789))
>> 
>> let str = abc[15..<17].asString  // Copy to to normal Swift String
>> print(str)
>> 
>> let s = "\(abc[12..<20])" // interpolate to normal Swift String.
>> print(s)
>> 
>> abc[3..<5] = TGString("34") // if lengths don't match:
>> abc[8...9] = ABC[24...25]   //  length of dest. string is altered.
>> abc[12] = TGString("")  //  if src l > 1 will insert remainder after 
>> dest.12 here
>> abc[14] = TGString("")  //  empty removes character at pos.
>> print(abc)
>>

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hi David & Dave

can you explain that in more detail?
>> Wouldn’t that turn simple character access into a mutating function?

assigning like   s[11…14] = str  is of course, yes.
only then - that is if the character array thus has been changed - 
it has to update the string in storage, yes. 

but  str = s[n.. On 24 Feb 2017, at 22:40, Dave Abrahams  wrote:
> 
> 
> 
> Sent from my moss-covered three-handled family gradunza
> 
> On Feb 23, 2017, at 2:04 PM, Ted F.A. van Gaalen  > wrote:
> 
>> 
>>> On 23 Feb 2017, at 02:24, Dave Abrahams >> > wrote:
>>> 
>>> Equally a non-starter. All known threadsafe schemes that require caches to 
>>> be updated upon non-mutating operations have horrible performance issues, 
>>> and further this would penalize all string code by reserving space for the 
>>> cache and filling it even for the vast majority of operations that don't 
>>> require random access. 
>> Well, maybe “caching” is not the right description for what I've suggested.
>> It is more like:
>>   let all strings be stored as they are now, but as soon as you want to work 
>> with 
>> random accessing parts of a string just “lift the string out of normal 
>> optimised string storage” 
>>  and then add (temporarily)  a Character array so one can work with this 
>> array directly ” 
> 
> That's a cache.
> 
>> which implies that all other strings remain as they are.  ergo: efficiency 
>> is only reduced for the “elevated” strings,
> 
> You have to add that temporary array somewhere.  The performance of every 
> string is penalized for that storage, and also for the cost of throwing it 
> out upon mutation. Every branch counts. 
> 
>> Using e.g. str.freeSpace(), if necessary, would then place the String back 
>> in its normal storage domain, thereby disposing the Character array
>> associated with it. 
> 
> Avoiding hidden dynamic storage overhead that needs to be freed is an 
> explicit goal of the design (see the section on String and Substring).
> 
>>> Trust me, we've gotten lots of such suggestions and thought through the 
>>> implications of each one very carefully.  
>> That’s good, because it means, that a lot of people are interested in this 
>> subject and wish to help.  
>> Of course you’ll get many of suggestions that might not be very useful, 
>> perhaps like this one... but sometimes suddenly someone 
>> comes along with things that might never have occurred to you. 
>> That is the beautiful nature of ideas…
> 
> But at some point, I hope you'll understand, I also have to say that I think 
> all the simple schemes have been adequately explored and the complex ones all 
> seem to have this basic property of relying on caches, which has unacceptable 
> performance, complexity, and, yes, usability costs. Analyzing and refuting 
> each one in detail begins to be a waste of time after that.  I'm not really 
> willing to go further down this road unless someone has an implementation and 
> experimental evidence that demonstrates it as non-problematic. 
> 
> 
>>> I'm afraid you will have to accept being disappointed about this. 
>> Well, like most developers, I am a stubborn kind of guy.. 
>> Luckily Swift is very flexible like Lego, so I rolled my own convenience 
>> struct.
>> If I need direct access on a string I simply copy the string to it.
>> it permits things like this:  (and growing) 
>> 
>> let strabc = "abcdefghjiklmnopqrstuvwxyz"
>> let strABC = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
>> var abc = TGString(strabc)
>> var ABC = TGString(strABC)
>> 
>> func test()
>> {
>> // as in Basic: left$, mid$, right$
>> print(abc.left(5))
>> print(abc.mid(5,10))
>> print(ABC.mid(5))
>> print(ABC.right(5))
>> 
>> // ranges and concatenation:
>> print(abc[12..<23])
>> print(abc.left(5) + ABC.mid(6,6) + abc[10...25])
>> 
>> // eat anything:
>> let d:Double = -3.14159
>> print(TGString(d))
>>  
>> let n:Int = 1234
>> print(TGString(n))
>> 
>> print(TGString(1234.56789))
>> 
>> let str = abc[15..<17].asString  // Copy to to normal Swift String
>> print(str)
>> 
>> let s = "\(abc[12..<20])" // interpolate to normal Swift String.
>> print(s)
>> 
>> abc[3..<5] = TGString("34") // if lengths don't match:
>> abc[8...9] = ABC[24...25]   //  length of dest. string is altered.
>> abc[12] = TGString("")  //  if src l > 1 will insert remainder after 
>> dest.12 here
>> abc[14] = TGString("")  //  empty removes character at pos.
>> print(abc)
>> abc.insert(at: 3, string: ABC[0..<3])
>> print(abc)
>> }
>>  
>> test()
>> .
>> outputs: 
>> abcde
>> fghjiklmno
>> FGHIJKLMNOPQRSTUVWXYZ
>> VWXYZ
>> mnopqrstuvw
>> 

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

> On 23 Feb 2017, at 02:24, Dave Abrahams  wrote:
> 
> Equally a non-starter. All known threadsafe schemes that require caches to be 
> updated upon non-mutating operations have horrible performance issues, and 
> further this would penalize all string code by reserving space for the cache 
> and filling it even for the vast majority of operations that don't require 
> random access.
Well, maybe “caching” is not the right description for what I've suggested.
It is more like:
  let all strings be stored as they are now, but as soon as you want to work 
with 
random accessing parts of a string just “lift the string out of normal 
optimised string storage” 
 and then add (temporarily)  a Character array so one can work with this array 
directly ” 
which implies that all other strings remain as they are.  ergo: efficiency 
is only reduced for the “elevated” strings,
Using e.g. str.freeSpace(), if necessary, would then place the String back 
in its normal storage domain, thereby disposing the Character array
associated with it. 
   

> Trust me, we've gotten lots of such suggestions and thought through the 
> implications of each one very carefully.  
That’s good, because it means, that a lot of people are interested in this 
subject and wish to help.  
Of course you’ll get many of suggestions that might not be very useful, 
perhaps like this one... but sometimes suddenly someone 
comes along with things that might never have occurred to you. 
That is the beautiful nature of ideas…

> I'm afraid you will have to accept being disappointed about this. 
Well, like most developers, I am a stubborn kind of guy.. 
Luckily Swift is very flexible like Lego, so I rolled my own convenience struct.
If I need direct access on a string I simply copy the string to it.
it permits things like this:  (and growing) 

let strabc = "abcdefghjiklmnopqrstuvwxyz"
let strABC = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
var abc = TGString(strabc)
var ABC = TGString(strABC)

func test()
{
// as in Basic: left$, mid$, right$
print(abc.left(5))
print(abc.mid(5,10))
print(ABC.mid(5))
print(ABC.right(5))

// ranges and concatenation:
print(abc[12..<23])
print(abc.left(5) + ABC.mid(6,6) + abc[10...25])

// eat anything:
let d:Double = -3.14159
print(TGString(d))
 
let n:Int = 1234
print(TGString(n))

print(TGString(1234.56789))

let str = abc[15..<17].asString  // Copy to to normal Swift String
print(str)

let s = "\(abc[12..<20])" // interpolate to normal Swift String.
print(s)

abc[3..<5] = TGString("34") // if lengths don't match:
abc[8...9] = ABC[24...25]   //  length of dest. string is altered.
abc[12] = TGString("")  //  if src l > 1 will insert remainder after 
dest.12 here
abc[14] = TGString("")  //  empty removes character at pos.
print(abc)
abc.insert(at: 3, string: ABC[0..<3])
print(abc)
}
 
test()
.
outputs: 
abcde
fghjiklmno
FGHIJKLMNOPQRSTUVWXYZ
VWXYZ
mnopqrstuvw
abcdeGHIJKLklmnopqrstuvwxyz
-3.14159
1234
1234.56789
abcdefghjiklmnopqrstuvwxyz
mnopqrst
abc34fghYZklnopqrstuvwxyz
abcABC34fghYZklnopqrstuvwxyz

kinda hoped that this could be builtin in Swift strings 
Anyway, I’ve made myself what I wanted, which happily co-exists
alongside normal Swift strings.  Performance and storage
aspects of my struct TGString are not very important, because
I am not using this on thousands of strings.
Simply want to use a string as a plain array, that’s all, 
which is implemented in almost every PL on this planet. 


> More generally, there's a reason that the collection model has bidirectional 
> and random access distinctions: important data structures are inherently not 
> random access.
I don’t understand the above line: definition of “important data structures” <> 
“inherently” 
> Heroic attempts to present the illusion that they are randomly-accessible are 
> not going to fly.
  ?? Accessing discrete elements directly in an array is not an illusion to me. 
(e.g. I took the 4th and 7th eggs from the container) 
> These abstractions always break down,  leaking the true non-random-access 
> nature in often unpredictable ways, penalizing lots of code for the sake of a 
> very few use-cases, and introducing complexity that is hard for the optimizer 
> to digest and makes it painful (sometimes impossible) to grow and evolve the 
> library.  
> 
Is an Array an abstraction? of what? I don’t get this either. most components 
in the real world can be accessed randomly. 

> This should be seen as a general design philosophy: Swift presents 
> abstractions that harmonize with, rather than hide, the true nature of things.
The true nature of things is a very vague and subjective criterium, how can you 
harmonise with that, let alone with abstractions? 
e.g. for me: “the true nature of things” for an array is that it has direct 
accessible discrete elements…

Sorry, with respect, we have a difference of 

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

   var s = str[10..<28]
if str[p1..<p1+ length] ==  “Dakota” {…}
   notes[bar1..<bar1+6] = “EADGBE”  
etc. 

   (try to do this with the existing string handling functions..)
   and also roll your own string handling functions directly
  based on subscripting. possibly in own extensions.
? 

In that way we can forget the imho  -sorry, excuse l’moi-  awkward and tedious 
constructions like: 
str.substringWithRange(Range(start: str.startIndex, end: 
str.endIndex))
horrible, too much typing, can’t read these things, have to look them up each 
time..
? 
Kind Regards
TedvG
( I am Dutch and living in Germany (like being here but it doesn’t help my 
English much :o) )
www.tedvg.com <http://www.tedvg.com/>
www.ravelnotes.com <http://www.ravelnotes.com/>
 


> 
> Note that you get random access AND safety by operating at the Character 
> level. If you operate at the unicode scalar value level instead, you might be 
> splitting canonical combining sequences accidentally.
> 
> 
>> On Feb 22, 2017, at 7:56 AM, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi Ben,
>> thank you, yes, I know all that by now. 
>> 
>> Have seen that one goes to great lengths to optimise, not only for storage 
>> but also for speed. But how far does this need to go?  In any case, 
>> optimisation should not be used
>> as an argument for restricting a PLs functionality that is to refrain from 
>> PL elements which are common and useful.?
>> 
>> I wouldn’t worry so much over storage (unless one wants to load a complete 
>> book into memory… in iOS, the average app is about 15-50 MB, String data is 
>> mostly a fraction of that. In macOS or similar I’d think it is even less 
>> significant…
>> 
>> I wonder how much performance and memory consumption would be different from 
>> the current contiguous memory implementation?  if a String is just is a 
>> plain row of (references to) Character (extended grapheme cluster) objects, 
>> Array<[Character>, which would simplify the basic logic and (sub)string 
>> handling significantly, because then one has direct access to the String’s 
>> elements directly, using the reasonably fast access methods of a Swift 
>> Collection/Array. 
>> 
>> I have experimented  with an alternative String struct based upon 
>> Array, seeing how easy it was to implement most popular string 
>> handling functions as one can work with the Character array directly. 
>> 
>> Currently at deep-dive-depth in the standard lib sources, especially String 
>> & Co.
>> 
>> Kind Regards
>> TedvG
>> 
>> 
>>> On 21 Feb 2017, at 01:31, Ben Cohen <ben_co...@apple.com 
>>> <mailto:ben_co...@apple.com>> wrote:
>>> 
>>> Hi Ted,
>>> 
>>> While Character is the Element type for String, it would be unsuitable for 
>>> a String’s implementation to actually use Character for storage. Character 
>>> is fairly large (currently 9 bytes), very little of which is used for most 
>>> values. For unusual graphemes that require more storage, it allocates more 
>>> memory on the heap. By contrast, String’s actual storage is a buffer of 1- 
>>> or 2-byte elements, and all graphemes (what we expose as Characters) are 
>>> held in that contiguous memory no matter how many code points they 
>>> comprise. When you iterate over the string, the graphemes are unpacked into 
>>> a Character on the fly. This gives you an user interface of a collection 
>>> that superficially appears to resemble [Character], but this does not mean 
>>> that this would be a workable implementation.
>>> 
>>>> On Feb 20, 2017, at 12:59 PM, Ted F.A. van Gaalen <tedvgios...@gmail.com 
>>>> <mailto:tedvgios...@gmail.com>> wrote:
>>>> 
>>>> Hi Ben, Dave (you should not read this now, you’re on vacation :o)  & 
>>>> Others
>>>> 
>>>> As described in the Swift Standard Library API Reference:
>>>> 
>>>> The Character type represents a character made up of one or more Unicode 
>>>> scalar values, 
>>>> grouped by a Unicode boundary algorithm. Generally, a Character instance 
>>>> matches what 
>>>> the reader of a string will perceive as a single character. The number of 
>>>> visible characters is 
>>>> generally the most natural way to count the length of a string.
>>>> The smallest discrete unit we (app programmers) are mostly working with is 
>>>> this

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hi Ben,
thank you, yes, I know all that by now. 

Have seen that one goes to great lengths to optimise, not only for storage but 
also for speed. But how far does this need to go?  In any case, optimisation 
should not be used
as an argument for restricting a PLs functionality that is to refrain from PL 
elements which are common and useful.?

I wouldn’t worry so much over storage (unless one wants to load a complete book 
into memory… in iOS, the average app is about 15-50 MB, String data is mostly a 
fraction of that. In macOS or similar I’d think it is even less significant…

I wonder how much performance and memory consumption would be different from 
the current contiguous memory implementation?  if a String is just is a plain 
row of (references to) Character (extended grapheme cluster) objects, 
Array<[Character>, which would simplify the basic logic and (sub)string 
handling significantly, because then one has direct access to the String’s 
elements directly, using the reasonably fast access methods of a Swift 
Collection/Array. 

I have experimented  with an alternative String struct based upon 
Array, seeing how easy it was to implement most popular string 
handling functions as one can work with the Character array directly. 

Currently at deep-dive-depth in the standard lib sources, especially String & 
Co.

Kind Regards
TedvG


> On 21 Feb 2017, at 01:31, Ben Cohen  wrote:
> 
> Hi Ted,
> 
> While Character is the Element type for String, it would be unsuitable for a 
> String’s implementation to actually use Character for storage. Character is 
> fairly large (currently 9 bytes), very little of which is used for most 
> values. For unusual graphemes that require more storage, it allocates more 
> memory on the heap. By contrast, String’s actual storage is a buffer of 1- or 
> 2-byte elements, and all graphemes (what we expose as Characters) are held in 
> that contiguous memory no matter how many code points they comprise. When you 
> iterate over the string, the graphemes are unpacked into a Character on the 
> fly. This gives you an user interface of a collection that superficially 
> appears to resemble [Character], but this does not mean that this would be a 
> workable implementation.
> 
>> On Feb 20, 2017, at 12:59 PM, Ted F.A. van Gaalen > > wrote:
>> 
>> Hi Ben, Dave (you should not read this now, you’re on vacation :o)  & Others
>> 
>> As described in the Swift Standard Library API Reference:
>> 
>> The Character type represents a character made up of one or more Unicode 
>> scalar values, 
>> grouped by a Unicode boundary algorithm. Generally, a Character instance 
>> matches what 
>> the reader of a string will perceive as a single character. The number of 
>> visible characters is 
>> generally the most natural way to count the length of a string.
>> The smallest discrete unit we (app programmers) are mostly working with is 
>> this
>> perceived visible character, what else? 
>> 
>> If that is the case, my reasoning is, that Strings (could / should? ) be 
>> relatively simple, 
>> because most, if not all, complexity of Unicode is confined within the 
>> Character object and
>> completely hidden**  for the average application programmer, who normally 
>> only needs
>> to work with Strings which contains these visible Characters, right? 
>> It doesn’t then make no difference at all “what’ is in” the Character, 
>> (excellent implementation btw) 
>> (Unicode, ASCCII, EBCDIC, Elvish, KlingonIV, IntergalacticV.2, whatever)
>> because we rely in sublime oblivion for the visually representation of 
>> whatever is in
>> the Character on miraculous font processors hidden in the dark depths of the 
>> OS. 
>> 
>> Then, in this perspective, my question is: why is String not implemented as 
>> directly based upon an array [Character]  ? In that case one can refer to 
>> the Characters of the
>> String directly, not only for direct subscripting and other String 
>> functionality in an efficient way. 
>> (i do hava scope of independent Swift here, that is interaction with 
>> libraries should be 
>> solved by the compiler, so as not to be restricted by legacy ObjC etc. 
>> 
>> **   (expect if one needs to do e.g. access individual elements and/or 
>> compose graphics directly?
>>   but for  this purpose the Character’s properties are accessible) 
>> 
>> For the sake of convenience, based upon the above reasoning,  I now 
>> “emulate" this in 
>> a string extension, thereby ignoring the rare cases that a visible character 
>> could be based 
>> upon more than a single Character (extended grapheme cluster)  If that would 
>> occur, 
>> thye should be merged into one extended grapheme cluster, a single Character 
>> that is. 
>> 
>> //: Playground - implement direct subscripting using a Character array
>> // of course, when the String is defined as an array of Characters, directly
>> // accessible it would be more 

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hi Ben, Dave (you should not read this now, you’re on vacation :o)  & Others

As described in the Swift Standard Library API Reference:

The Character type represents a character made up of one or more Unicode scalar 
values, 
grouped by a Unicode boundary algorithm. Generally, a Character instance 
matches what 
the reader of a string will perceive as a single character. The number of 
visible characters is 
generally the most natural way to count the length of a string.
The smallest discrete unit we (app programmers) are mostly working with is this
perceived visible character, what else? 

If that is the case, my reasoning is, that Strings (could / should? ) be 
relatively simple, 
because most, if not all, complexity of Unicode is confined within the 
Character object and
completely hidden**  for the average application programmer, who normally only 
needs
to work with Strings which contains these visible Characters, right? 
It doesn’t then make no difference at all “what’ is in” the Character, 
(excellent implementation btw) 
(Unicode, ASCCII, EBCDIC, Elvish, KlingonIV, IntergalacticV.2, whatever)
because we rely in sublime oblivion for the visually representation of whatever 
is in
the Character on miraculous font processors hidden in the dark depths of the 
OS. 

Then, in this perspective, my question is: why is String not implemented as 
directly based upon an array [Character]  ? In that case one can refer to the 
Characters of the
String directly, not only for direct subscripting and other String 
functionality in an efficient way. 
(i do hava scope of independent Swift here, that is interaction with libraries 
should be 
solved by the compiler, so as not to be restricted by legacy ObjC etc. 

**   (expect if one needs to do e.g. access individual elements and/or compose 
graphics directly?
  but for  this purpose the Character’s properties are accessible) 

For the sake of convenience, based upon the above reasoning,  I now “emulate" 
this in 
a string extension, thereby ignoring the rare cases that a visible character 
could be based 
upon more than a single Character (extended grapheme cluster)  If that would 
occur, 
thye should be merged into one extended grapheme cluster, a single Character 
that is. 

//: Playground - implement direct subscripting using a Character array
// of course, when the String is defined as an array of Characters, directly
// accessible it would be more efficient as in these extension functions. 
extension String
{
var count: Int
{
get
{
return self.characters.count
}
}

subscript (n: Int) -> String
{
return String(Array(self.characters)[n])
}

subscript (r: Range) -> String
{
return String(Array(self.characters)[r])
}

subscript (r: ClosedRange) -> String
{
return String(Array(self.characters)[r])
}
}

func test()
{
let zoo = "Koala , Snail , Penguin , Dromedary "
print("zoo has \(zoo.count) characters (discrete extended graphemes):")
for i in 0..___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

  10  ALTERNATE-CONTACT.
>>15  TITLE   PIC X(10).
>>15  LAST-NAME   PIC X(15).
>>15  FIRST-NAME  PIC X(8).
>>05  ADDRESS PIC X(15).
>>05  CITYPIC X(15).
>>05  STATE   PIC XX.
>>05  ZIP PIC 9(5).
>> 
>> These are all character data fields here, except for the numeric ZIP field , 
>> however in Cobol it can be treated like character data. 
>> So here I am, having to get the data of these old Cobol production files
>> into a brand new Swift based accounting system of 2017, what can I do?   
>> 
>> How do I unpack these records and being the data into a Swift structure or 
>> class? 
>> (In Cobol I don’t have to because of the predefined fixed format record 
>> layout).
>> 
>> AFAIK there are no similar record structures with fixed fields like this 
>> available Swift?
>> 
>> So, the only way I can think of right now is to do it like this:
>> 
>> // mailingRecord is a Swift structure
>> struct MailingRecord
>> {
>> var  companyName: String = “no Name”
>>  var contacts: CompanyContacts
>>  .
>>  etc.. 
>> }
>> 
>> // recordStr was read here with ASCII encoding
>> 
>> // unpack data in to structure’s properties, in this case all are Strings
>> mailingRecord.companyName   = recordStr[ 0..<30]
>> mailingRecord.contacts.president.lastName  = recordStr[30..<45]
>> mailingRecord.contacts.president.firstName = recordStr[45..<53]
>> 
>> 
>> // and so on..
>> 
>> Ever worked for e.g. a bank with thousands of these files unchanged formats 
>> for years?
>> 
>> Any alternative, convenient en simpler methods in Swift present? 
>> 
>> Kind Regards
>> TedvG
>> ( example of the above Cobol record borrowed from here: 
>>  
>> http://www.3480-3590-data-conversion.com/article-reading-cobol-layouts-1.html
>>  
>> <http://www.3480-3590-data-conversion.com/article-reading-cobol-layouts-1.html>
>>   ) 
>> 
>> 
>> 
>> 
>>> 
>>>>> On 9 Feb 2017, at 16:48, Shawn Erickson <shaw...@gmail.com 
>>>>> <mailto:shaw...@gmail.com>> wrote:
>>>>> 
>>>>> I also wonder what folks are actually doing that require indexing
>>>>> into strings. I would love to see some real world examples of what
>>>>> and why indexing into a string is needed. Who is the end consumer of
>>>>> that string, etc.
>>>>> 
>>>>> Do folks have so examples?
>>>>> 
>>>>> -Shawn
>>>>> 
>>>>> On Thu, Feb 9, 2017 at 6:56 AM Ted F.A. van Gaalen via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> 
>>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> 
>>>>> wrote:
>>>>> Hello Hooman
>>>>> That invalidates my assumptions, thanks for evaluating
>>>>> it's more complex than I thought.
>>>>> Kind Regards
>>>>> Ted
>>>>> 
>>>>>> On 8 Feb 2017, at 00:07, Hooman Mehr <hoo...@mac.com 
>>>>>> <mailto:hoo...@mac.com> <mailto:hoo...@mac.com <mailto:hoo...@mac.com>>> 
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution 
>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> 
>>>>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> I now assume that:
>>>>>>>  1. -= a “plain” Unicode character (codepoint?)  can result in one 
>>>>>>> glyph.=-
>>>>>> 
>>>>>> What do you mean by “plain”? Characters in some Unicode scripts are
>>>>>> by no means “plain”. They can affect (and be affected by) the
>>>>>> characters around them, they can cause glyphs around them to
>>>>>> rearrange or combine (like ligatures) or their visual
>>>>>> representation (glyph) may float in the same space as an adjacent
>>>>>> glyph (and seem to be part of the “host” glyph), etc. So, the
>>>>>> general relationship of a character and its corresponding glyph (if
>>>>>> there is one) is complex and depends on context and surroundings
>>>>>> characters.
>>>>>> 
>>>>>>>  2. -= a  grapheme cluster always results in just a single glyph, 
>>>>>>> true? =- 
>>>>>> 
>>>>>> False
>>>>>> 
>>>>>>>  3. The only thing that I can see on screen or print are glyphs 
>>>>>>> (“carvings”,visual elements that stand on their own )
>>>>>> 
>>>>>> The visible effect might not be a visual shape. It may be for example, 
>>>>>> the way the surrounding shapes change or re-arrange.
>>>>>> 
>>>>>>> 4.  In this context, a glyph is a humanly recognisable visual form 
>>>>>>> of a character,
>>>>>> 
>>>>>> Not in a straightforward one to one fashion, not even in Latin / Roman 
>>>>>> script.
>>>>>> 
>>>>>>> 5. On this level (the glyph, what I can see as a user) it is not 
>>>>>>> relevant and also not detectable
>>>>>>> with how many Unicode scalars (codepoints ?), grapheme, or even 
>>>>>>> on what kind
>>>>>>> of encoding the glyph was based upon.
>>>>>> 
>>>>>> False
>>>>>> 
>>>>> 
>>>>> ___
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> 
>>>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>>
>>>> 
>>> 
>>> -- 
>>> -Dave
>> 

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Please see in-line response below
> On 10 Feb 2017, at 03:56, Shawn Erickson  wrote:
> 
> 
> On Thu, Feb 9, 2017 at 5:09 PM Ted F.A. van Gaalen  > wrote:
>> On 10 Feb 2017, at 00:11, Dave Abrahams > > wrote:
>> 
>> 
>> on Thu Feb 09 2017, "Ted F.A. van Gaalen" > > wrote:
>> 
>>> Hello Shawn
>>> Just google with any programming language name and “string manipulation”
>>> and you have enough reading for a week or so :o)
>>> TedvG
>> 
>> That truly doesn't answer the question.  It's not, “why do people index
>> strings with integers when that's the only tool they are given for
>> decomposing strings?”  It's, “what do you have to do with strings that's
>> hard in Swift *because* you can't index them with integers?”
> 
> Hi Dave,
> Ok. here are just a few examples: 
> Parsing and validating an ISBN code? or a (freight) container ID? or EAN13 
> perhaps? 
> of many of the typical combined article codes and product IDs that many 
> factories and shops use? 
> 
> or: 
> 
> E.g. processing legacy files from IBM mainframes:
> extract fields from ancient data records read from very old sequential files,
> say, a product data record like this from a file from 1978 you’d have to 
> unpack and process:   
> 123534-09EVXD4568,991234,89ABCYELLOW12AGRAINESYTEMZ3453
> into:
> 123, 534, -09, EVXD45, 68,99, 1234,99, ABC, YELLOW, 12A, GRAIN, ESYSTEM, 
> Z3453.
> product category, pcs, discount code, product code, price Yen, price $, class 
> code, etc… 
> in Cobol and PL/1 records are nearly always defined with a fixed field layout 
> like this.:
> (storage was limited and very, very expensive, e.g. XML would be regarded as 
> a 
> "scandalous waste" even the commas in CSV files! ) 
> 
> 01  MAILING-RECORD.
>05  COMPANY-NAMEPIC X(30).
>05  CONTACTS.
>10  PRESIDENT.
>15  LAST-NAME   PIC X(15).
>15  FIRST-NAME  PIC X(8).
>10  VP-MARKETING.
>15  LAST-NAME   PIC X(15).
>15  FIRST-NAME  PIC X(8).
>10  ALTERNATE-CONTACT.
>15  TITLE   PIC X(10).
>15  LAST-NAME   PIC X(15).
>15  FIRST-NAME  PIC X(8).
>05  ADDRESS PIC X(15).
>05  CITYPIC X(15).
>05  STATE   PIC XX.
>05  ZIP PIC 9(5).
> 
> These are all character data fields here, except for the numeric ZIP field , 
> however in Cobol it can be treated like character data. 
> So here I am, having to get the data of these old Cobol production files
> into a brand new Swift based accounting system of 2017, what can I do?   
> 
> How do I unpack these records and being the data into a Swift structure or 
> class? 
> (In Cobol I don’t have to because of the predefined fixed format record 
> layout).
> 
> AFAIK there are no similar record structures with fixed fields like this 
> available Swift?
> 
> So, the only way I can think of right now is to do it like this:
> 
> // mailingRecord is a Swift structure
> struct MailingRecord
> {
> var  companyName: String = “no Name”
>  var contacts: CompanyContacts
>  .
>  etc.. 
> }
> 
> // recordStr was read here with ASCII encoding
> 
> // unpack data in to structure’s properties, in this case all are Strings
> mailingRecord.companyName   = recordStr[ 0..<30]
> mailingRecord.contacts.president.lastName  = recordStr[30..<45]
> mailingRecord.contacts.president.firstName = recordStr[45..<53]
> 
> 
> // and so on..
> 
> Ever worked for e.g. a bank with thousands of these files unchanged formats 
> for years?
> 
> Any alternative, convenient en simpler methods in Swift present? 
> These looks like examples of fix data format
Hi Shawn,
No, it could also be an UTF-8 String.
  
> that could be parsed from a byte buffer into strings, etc.
How would you do that? could you please provide an example how to do this, with 
a byte buffer? 
eg. read from flat ascii file —> unpack fields —> store in structure props? 


> Likely little need to force them via a higher order string concept,
What do you mean here with “high order string concept” ??
Swift is a high level language, I expect to do this with Strings directly,
instead of being forced to use low-level coding with byte arrays etc.
(I have/want no time for that)
Surely, one doesn’t have to resort to that in a high level language like Swift? 
If I am certain that all characters in a file etc. are of fixed width, even in 
UTF-32
(in the above example I am 100% sure of that) then 
using  str[n1..

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hello Shawn
Just google with any programming language name and “string manipulation”
and you have enough reading for a week or so :o)
TedvG


> On 9 Feb 2017, at 16:48, Shawn Erickson <shaw...@gmail.com> wrote:
> 
> I also wonder what folks are actually doing that require indexing into 
> strings. I would love to see some real world examples of what and why 
> indexing into a string is needed. Who is the end consumer of that string, etc.
> 
> Do folks have so examples?
> 
> -Shawn
> 
> On Thu, Feb 9, 2017 at 6:56 AM Ted F.A. van Gaalen via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hello Hooman
> That invalidates my assumptions, thanks for evaluating
> it's more complex than I thought.
> Kind Regards
> Ted
> 
>> On 8 Feb 2017, at 00:07, Hooman Mehr <hoo...@mac.com 
>> <mailto:hoo...@mac.com>> wrote:
>> 
>> 
>>> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I now assume that:
>>>   1. -= a “plain” Unicode character (codepoint?)  can result in one 
>>> glyph.=-
>> 
>> What do you mean by “plain”? Characters in some Unicode scripts are by no 
>> means “plain”. They can affect (and be affected by) the characters around 
>> them, they can cause glyphs around them to rearrange or combine (like 
>> ligatures) or their visual representation (glyph) may float in the same 
>> space as an adjacent glyph (and seem to be part of the “host” glyph), etc. 
>> So, the general relationship of a character and its corresponding glyph (if 
>> there is one) is complex and depends on context and surroundings characters.
>> 
>>>   2. -= a  grapheme cluster always results in just a single glyph, 
>>> true? =- 
>> 
>> False
>> 
>>>   3. The only thing that I can see on screen or print are glyphs 
>>> (“carvings”,visual elements that stand on their own )
>> 
>> The visible effect might not be a visual shape. It may be for example, the 
>> way the surrounding shapes change or re-arrange.
>> 
>>>  4.  In this context, a glyph is a humanly recognisable visual form of 
>>> a character,
>> 
>> Not in a straightforward one to one fashion, not even in Latin / Roman 
>> script.
>> 
>>>  5. On this level (the glyph, what I can see as a user) it is not 
>>> relevant and also not detectable
>>>  with how many Unicode scalars (codepoints ?), grapheme, or even on 
>>> what kind
>>>  of encoding the glyph was based upon.
>> 
>> False
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <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] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hello Hooman
That invalidates my assumptions, thanks for evaluating
it's more complex than I thought.
Kind Regards
Ted

> On 8 Feb 2017, at 00:07, Hooman Mehr <hoo...@mac.com> wrote:
> 
> 
>> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I now assume that:
>>   1. -= a “plain” Unicode character (codepoint?)  can result in one 
>> glyph.=-
> 
> What do you mean by “plain”? Characters in some Unicode scripts are by no 
> means “plain”. They can affect (and be affected by) the characters around 
> them, they can cause glyphs around them to rearrange or combine (like 
> ligatures) or their visual representation (glyph) may float in the same space 
> as an adjacent glyph (and seem to be part of the “host” glyph), etc. So, the 
> general relationship of a character and its corresponding glyph (if there is 
> one) is complex and depends on context and surroundings characters.
> 
>>   2. -= a  grapheme cluster always results in just a single glyph, true? 
>> =- 
> 
> False
> 
>>   3. The only thing that I can see on screen or print are glyphs 
>> (“carvings”,visual elements that stand on their own )
> 
> The visible effect might not be a visual shape. It may be for example, the 
> way the surrounding shapes change or re-arrange.
> 
>>  4.  In this context, a glyph is a humanly recognisable visual form of a 
>> character,
> 
> Not in a straightforward one to one fashion, not even in Latin / Roman script.
> 
>>  5. On this level (the glyph, what I can see as a user) it is not 
>> relevant and also not detectable
>>  with how many Unicode scalars (codepoints ?), grapheme, or even on 
>> what kind
>>  of encoding the glyph was based upon.
> 
> False
> 

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

> On 7 Feb 2017, at 19:44, Dave Abrahams <dabrah...@apple.com> wrote:
> 
> 
> on Tue Feb 07 2017, "Ted F.A. van Gaalen"  wrote:
> 
>>> On 7 Feb 2017, at 05:42, Karl Wagner <razie...@gmail.com> wrote:
>>> 
>>>> 
>>>> On 6 Feb 2017, at 19:29, Ted F.A. van Gaalen via swift-evolution 
>>>> <swift-evolution@swift.org
>> <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>> When it comes to fast access what’s most important is cache
>>> locality. DRAM is like 200x slower than L2 cache. Looping through
>>> some contiguous 16-bit integers is always going to beat the pants
>>> out of derefencing pointers.
>> 
>>> 
>> Hi Karl
>> That is of course hardware/processor dependent…and Swift runs on different 
>> target systems… isn’t? 
> 
> Actually the basic calculus holds for any modern processor.
> 
>>> It’s quite rare that you need to grab arbitrary parts of a String
>>> without knowing what is inside it. If you’re saying str[12..<34] -
>>> why 12, and why 34? Is 12 the length of some substring you know from
>>> earlier? In that case, you could find out how many CodeUnits it had,
>>> and use that information instead.
>>> For this example, I have used constants here, but normally these would be 
>>> variables..
>>> 
>> 
>> I’d say it is not so rare, these things are often used for all kinds of 
>> string parsing, there are
>> many
>> examples to be found on the Internet.
>> TedvG
> 
> That proves nothing, though.  The fact that people are using integers to
> do this doesn't mean you need to use them, nor does it mean that you'll
> get the right results from doing so.  Typically examples that use
> integer constants with strings are wrong for some large proportion of
> unicode text.
> 
  This is all a bit confusing.  
in https://en.wiktionary.org/wiki/glyph
   Definition of a glyph in our context: 
(typography, computing) A visual representation of a letter 
<https://en.wiktionary.org/wiki/letter>, character 
<https://en.wiktionary.org/wiki/character>, or symbol 
<https://en.wiktionary.org/wiki/symbol>, in a specific font 
<https://en.wiktionary.org/wiki/font> and style 
<https://en.wiktionary.org/wiki/style>.

I now assume that:
  1. -= a “plain” Unicode character (codepoint?)  can result in one glyph.=-
  2. -= a  grapheme cluster always results in just a single glyph, true? =- 
  3. The only thing that I can see on screen or print are glyphs 
(“carvings”,visual elements that stand on their own )
 4.  In this context, a glyph is a humanly recognisable visual form of a 
character,
 5. On this level (the glyph, what I can see as a user) it is not relevant 
and also not detectable
 with how many Unicode scalars (codepoints ?), grapheme, or even on 
what kind
 of encoding the glyph was based upon.

 is this correct? (especially 1 and 2) 

Based on these assumptions, to me then, the definition of a character == glyph.
Therefore, my working model: I see a row of characters as a row of glyphs,
which are discrete autonomous visual elements, ergo: 
Each element is individually addressable with integers (ordinal)

?

TedvG



   

> -- 
> -Dave

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Thanks ..seeing now all this being heavily intertwined with external libs ICU 
etc.
then yes, too much effort for too little (making fixed width Unicode strings)
Why am i doing this?  Unicode is a wasp nest, how do you survive, Dave ? :o) 

But I do use “random string access" e.g. extracting substrings
with e.g.  let part = str[3..<6]  
with the help of the aforementioned String extension..

arrgh, great, make me a tea...

TedvG

> On 6 Feb 2017, at 23:25, Dave Abrahams <dabrah...@apple.com> wrote:
> 
> 
> on Mon Feb 06 2017, David Waite  wrote:
> 
>>> On Feb 6, 2017, at 10:26 AM, Ted F.A. van Gaalen via swift-evolution 
>>> <swift-evolution@swift.org>
>> wrote:
>>> 
>>> Hi Dave,
>>> Oops! yes, you’re right!
>>> I did read again more thoroughly about Unicode 
>> 
>>> and how Unicode is handled within Swift...
>>> -should have done that before I write something- sorry.  
>>> 
>>> Nevertheless: 
>>> 
>>> How about this solution:  (if I am not making other omissions in my 
>>> thinking again) 
>>> -Store the string as a collection of fixed-width 32 bit UTF-32 characters 
>>> anyway.
>>> -however, if the Unicode character is a grapheme cluster (2..n Unicode 
>>> characters),then 
>>> store a pointer to a hidden child string containing the actual grapheme 
>>> cluster, like so:
>>> 
>>> 1: [UTF32, UTF32, UTF32, 1pointer,  UTF32, UTF32, 1pointer, UTF32, UTF32]
>>>|
>>>   |
>>> 2:   [UTF32, UTF32]  [UTF32, 
>>> UTF32, UTF32, ...]
>>> 
>>> whereby (1) is aString as seen by the programmer.
>>> and (2)  are hidden child strings, each containing a grapheme cluster. 
>> 
>> The random access would require a uniform layout, so a pointer and
>> scalar would need to be the same size. The above would work with a 32
>> bit platform with a tagged pointer, but would require a 64-bit slot
>> for pointers on 64-bit systems like macOS and iOS.
> 
> It would also make String not efficiently interoperable with almost any
> other system that processes strings including Foundation and ICU.
> 
>> Today when I need to do random access into a string, I convert it to
>> an Array. Hardly efficient memory-wise, but efficient
>> enough for random access.
> 
> I'd be willing to bet almost anything that you  never actually need to
> do random access into a String ;-)
> 
> -- 
> -Dave

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

> On 7 Feb 2017, at 05:42, Karl Wagner <razie...@gmail.com> wrote:
> 
>> 
>> On 6 Feb 2017, at 19:29, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>> On 6 Feb 2017, at 19:10, David Waite <da...@alkaline-solutions.com 
>>> <mailto:da...@alkaline-solutions.com>> wrote:
>>> 
>>>> 
>>>> On Feb 6, 2017, at 10:26 AM, Ted F.A. van Gaalen via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> Hi Dave,
>>>> Oops! yes, you’re right!
>>>> I did read again more thoroughly about Unicode 
>>>> and how Unicode is handled within Swift...
>>>> -should have done that before I write something- sorry.  
>>>> 
>>>> Nevertheless: 
>>>> 
>>>> How about this solution:  (if I am not making other omissions in my 
>>>> thinking again) 
>>>> -Store the string as a collection of fixed-width 32 bit UTF-32 characters 
>>>> anyway.
>>>> -however, if the Unicode character is a grapheme cluster (2..n Unicode 
>>>> characters),then 
>>>> store a pointer to a hidden child string containing the actual grapheme 
>>>> cluster, like so:
>>>> 
>>>> 1: [UTF32, UTF32, UTF32, 1pointer,  UTF32, UTF32, 1pointer, UTF32, UTF32]
>>>>|   
>>>>|
>>>> 2:   [UTF32, UTF32]  [UTF32, 
>>>> UTF32, UTF32, ...]
>>>> 
>>>> whereby (1) is aString as seen by the programmer.
>>>> and (2)  are hidden child strings, each containing a grapheme cluster. 
>>> 
>>> The random access would require a uniform layout, so a pointer and scalar 
>>> would need to be the same size. The above would work with a 32 bit platform 
>>> with a tagged pointer, but would require a 64-bit slot for pointers on 
>>> 64-bit systems like macOS and iOS.
>>> 
>> Yeah, I know that,  but the “grapheme cluster pool” I am imagining 
>> could be allocated at a certain predefined base address, 
>> whereby the pointer I am referring to is just an offset from this base 
>> address. 
>> If so, an address space of  2^30  (1,073,741,824) 1 GB, will be available,
>> which is more than sufficient for just storing unique grapheme clusters..
>> (of course, not taking in account other allocations and app limitations) 
> 
> When it comes to fast access what’s most important is cache locality. DRAM is 
> like 200x slower than L2 cache. Looping through some contiguous 16-bit 
> integers is always going to beat the pants out of derefencing pointers.
Hi Karl
That is of course hardware/processor dependent…and Swift runs on different 
target systems… isn’t? 
> 
>>   
>>> Today when I need to do random access into a string, I convert it to an 
>>> Array. Hardly efficient memory-wise, but efficient enough for 
>>> random access.
>>> 
>> As a programmer. I just want to use String as-is but with  direct 
>> subscripting like str[12..<34]
>> and, if possible also with open range like so: str[12…]   
>> implemented natively in Swift. 
>> 
>> Kind Regards
>> TedvG
>> www.tedvg.com <http://www.tedvg.com/>
>> www.ravelnotes.com <http://www.ravelnotes.com/>
>>  
>>> -DW
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> It’s quite rare that you need to grab arbitrary parts of a String without 
> knowing what is inside it. If you’re saying str[12..<34] - why 12, and why 
> 34? Is 12 the length of some substring you know from earlier? In that case, 
> you could find out how many CodeUnits it had, and use that information 
> instead.
For this example, I have used constants here, but normally these would be 
variables..
> 

I’d say it is not so rare, these things are often used for all kinds of string 
parsing, there are many
examples to be found on the Internet.
TedvG
> The new model will give you some form of efficient “random” access; the catch 
> is that it’s not totally random. Looking for the next character boundary is 
> necessarily linear, so the trick for large strings (>16K) is to make sure you 
> remember the CodeUnit offsets of important character boundaries.
> 
> - Karl

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

> On 6 Feb 2017, at 19:10, David Waite <da...@alkaline-solutions.com> wrote:
> 
>> 
>> On Feb 6, 2017, at 10:26 AM, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hi Dave,
>> Oops! yes, you’re right!
>> I did read again more thoroughly about Unicode 
>> and how Unicode is handled within Swift...
>> -should have done that before I write something- sorry.  
>> 
>> Nevertheless: 
>> 
>> How about this solution:  (if I am not making other omissions in my thinking 
>> again) 
>> -Store the string as a collection of fixed-width 32 bit UTF-32 characters 
>> anyway.
>> -however, if the Unicode character is a grapheme cluster (2..n Unicode 
>> characters),then 
>> store a pointer to a hidden child string containing the actual grapheme 
>> cluster, like so:
>> 
>> 1: [UTF32, UTF32, UTF32, 1pointer,  UTF32, UTF32, 1pointer, UTF32, UTF32]
>>| 
>>  |
>> 2:   [UTF32, UTF32]  [UTF32, 
>> UTF32, UTF32, ...]
>> 
>> whereby (1) is aString as seen by the programmer.
>> and (2)  are hidden child strings, each containing a grapheme cluster. 
> 
> The random access would require a uniform layout, so a pointer and scalar 
> would need to be the same size. The above would work with a 32 bit platform 
> with a tagged pointer, but would require a 64-bit slot for pointers on 64-bit 
> systems like macOS and iOS.
> 
Yeah, I know that,  but the “grapheme cluster pool” I am imagining 
could be allocated at a certain predefined base address, 
whereby the pointer I am referring to is just an offset from this base address. 
If so, an address space of  2^30  (1,073,741,824) 1 GB, will be available,
which is more than sufficient for just storing unique grapheme clusters..
(of course, not taking in account other allocations and app limitations) 
  
> Today when I need to do random access into a string, I convert it to an 
> Array. Hardly efficient memory-wise, but efficient enough for 
> random access.
> 
As a programmer. I just want to use String as-is but with  direct subscripting 
like str[12..<34]
and, if possible also with open range like so: str[12…]   
implemented natively in Swift. 

Kind Regards
TedvG
www.tedvg.com <http://www.tedvg.com/>
www.ravelnotes.com <http://www.ravelnotes.com/>
 
> -DW

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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

We know that:
The cumbersome complexity of current Swift String handling 
and programming is caused by the fact that Unicode characters 
are stored and processed as  streams/arrays with elements 
of variable-width (1...4 bytes for each character) Unicode characters.

Because of that, direct subscripting of string elements e.g. str[2..<18] 
is not possible.Therefore it was, and still is, not implemented in Swift,
much to the unpleasant surprise of many new Swift programmers 
coming from many other PLs like me. They did miss plain direct subscripting 
so much that the first thing ever they do before using Swift intensively is 
implementing the following or similar dreadful code (at least for direct 
subscripting),  and bury it deep into a String extension, once written, 
hopefully never to be seen again, like in this example: 

extension String
{
   subscript(i: Int) -> String
   {
guard i >= 0 && i < characters.count else { return "" }
return String(self[index(startIndex, offsetBy: i)])
}


subscript(range: Range) -> String
{
let lowerIndex = index(startIndex, offsetBy: max(0,range.lowerBound), 
limitedBy: endIndex) ?? endIndex
return substring(with: lowerIndex..<(index(lowerIndex, offsetBy: 
range.upperBound - range.lowerBound, limitedBy: endIndex) ?? endIndex))
}


subscript(range: ClosedRange) -> String
{
let lowerIndex = index(startIndex, offsetBy: max(0,range.lowerBound), 
limitedBy: endIndex) ?? endIndex
return substring(with: lowerIndex..<(index(lowerIndex, offsetBy: 
range.upperBound - range.lowerBound + 1, limitedBy: endIndex) ?? endIndex))
} 
 }

[splendid jolly good Earl Grey tea is now being served to help those 
flabbergasted to recover as quickly as possible.] 

This rather indirect and clumsy way of working with string data is because 
(with the exception of UTF-32 characters) Unicode characters come in 
variable-width encoding (1 to 4 bytes for each char), which as we know 
makes string handling for UTF-8, UTF-16 very complex and inefficient.
E.g. to isolate a substring it is necessary to sequentially 
traverse the string instead of direct access. 

However, that is not the case with UTF-32, because with UTF-32 encoding
each character has a fixed-width and always occupies exactly 4 bytes, 32 bit. 
Ergo: the problem can be easily solved: The simple solution is to always 
and without exception use UTF-32 encoding as Swift's internal 
string format because it only contains fixed width Unicode characters. 

Unicode strings with whatever UTF encoding as read into the program would 
be automatically converted to 32-bit UTF32 format. Note that explicit 
conversion 
e.g. back to UTF-8, can be specified or defaulted when writing Strings to a 
storage medium or URL etc. 

Possible but imho not recommended: The current String system could be pushed
down and kept alive (e.g. as Type StringUTF8?) as a secondary alternative to 
accommodate those that need to process very large quantities of text in core.


What y'all think?
Kind regards
TedvG
www.tedvg.com 
www.ravelnotes.com  
 




 



 

 


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

Re: [swift-evolution] Strings in Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hi Dave,
Oops! yes, you’re right!
I did read again more thoroughly about Unicode 
and how Unicode is handled within Swift...
-should have done that before I write something- sorry.  

Nevertheless: 

How about this solution:  (if I am not making other omissions in my thinking 
again) 
-Store the string as a collection of fixed-width 32 bit UTF-32 characters 
anyway.
-however, if the Unicode character is a grapheme cluster (2..n Unicode 
characters),then 
store a pointer to a hidden child string containing the actual grapheme 
cluster, like so:

1: [UTF32, UTF32, UTF32, 1pointer,  UTF32, UTF32, 1pointer, UTF32, UTF32]
|   
   |
2:   [UTF32, UTF32]  [UTF32, UTF32, 
UTF32, ...]

whereby (1) is aString as seen by the programmer.
and (2)  are hidden child strings, each containing a grapheme cluster. 

To make the distinction between a “plain” single UTF-32 char and a grapheme 
cluster, 
set the most significant bit of the 32 bit value to 1 and use the other 31 bits
as a pointer to another (hidden) String instance, containing the grapheme 
cluster. 
In this way, one could then also make graphemes within graphemes,  
but that is probably not desired? Another solution is to store the grapheme 
clusters
in a dedicated “grapheme pool’, containing the (unique as in aSet) grapheme 
clusters
encountered whenever a Unicode string (in whatever format) is read-in or 
defined at runtime. 

but then again.. seeing how hard it is to recognise Grapheme clusters in the 
first place.. 
? I don’t know. Unicode is complicated..  

Kind regards 
TedvG. 

www.tedvg.com 
www.ravelnotes.com 






> On 6 Feb 2017, at 05:15, Dave Abrahams  wrote:
> 
> 
> 
>> On Feb 5, 2017, at 2:57 PM, Ted F.A. van Gaalen  
>> wrote:
>> 
>> However, that is not the case with UTF-32, because with UTF-32 encoding
>> each character has a fixed-width and always occupies exactly 4 bytes, 32 
>> bit. 
>> Ergo: the problem can be easily solved: The simple solution is to always 
>> and without exception use UTF-32 encoding as Swift's internal 
>> string format because it only contains fixed width Unicode characters. 
> 
> Those are not (user-perceived) Characters; they are Unicode Scalar Values 
> (often called "characters" by the Unicode standard.  Characters as defined in 
> Swift (a.k.a. extended grapheme clusters) have no fixed-width encoding, and 
> Unicode scalar values are an inappropriate unit for most string processing. 
> Please read the manifesto for details.
> 
> Sent from my iPad

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

[swift-evolution] [:o)] Live well and prosper

[Ted F.A. van Gaalen via swift-evolution]

Hi Chris!
maybe a bit late, but I wish you all the best++ in your new position !!!
Very interesting company I think, have fun and ignore the [some words
out of range removed here] utter nonsense that some have written!
It is your life, not theirs, follow you heart and interests, be yourself! 
Yes, you can!

I am satisfied with how Swift is now, thanks to you and the Swift team.
It is excellent, I use it for iOS, macOS and TVOS.
it has everything I need.  Currently I needed to “revert" to C++ because I am 
currently
interested in micro controllers (R Pi, BlueFruit M0 (Bluetooth BLE with iPad 
app) , RX63N) and
lots of time for it. Yes, one can do crazy things when retired :o) I never get 
bored. 
C++ ;;; needs a bit of discipline, but in principle any PL is as good
or bad as the programmer using it., I can write unbelievable  sh.. in about
any language you give me, even in Swift :o)   
My favourite PL is still Smalltalk, I’ve tried to think about merging static 
language(s)
like Swift with dynamic Smalltalk, but I have the impression those worlds are 
too
far apart?..i could be wrong here.  I could write a lot more about this, but 
this is out-of-context in
SwiftEvolution I’d say. But the future is interesting, however, 
let us remain with hope because there are again elections in the US
in 4 years, yeah maybe even sooner i hope :o)
If you’d ever land in Speyer  I’ll buy you a beer (or two)! 
Kind Regards
TedvG___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Happy New Year !!!!!!!]

[Ted F.A. van Gaalen via swift-evolution]

Hey guys & girls, (arbitrary sequence :o)

Some of  You might perhaps have noticed that it is now 2016++ (oops 2017)

So wish each other al good things and events, and the most beautiful things
still to find in this mad world (it all depends how we deal with that and has 
always been that way)

Get some fresh air and enjoy yourself!
I am now 66 retired, have too live from not too much money, 
(hey Chris, send me your previous iMac 4K :o) 
but happy with the freedom with that the nervous worrying (in my case) about 
existence has ceased to exist. Recently I have been hit by 
the micro controller virus (e.g. Raspberry PI, Bluefruit M0 Bluefeather, RX63N) 
very cool.  You have now idea how insanely beautiful a generic red LED can glow 
when PWM modulated… Still in C++ but maybe in Swift later, who knows, perhaps 
a special MCU Swift variant (vendor (eg Atmel, Renesas etc.) supported 
can be brought to life, which would  allow direct port (is volatile memory 
mapped) access without 
all the (un)managed stuff. In the end my iPads should talk to them with 
Bluetooth BLE. 
[some current frustrations have been removed here]   

I still take a look at Swift evolution ca. every other day but I’ve lost track 
more or less..
still think more pragmatic and am perfectly happy with Swift 3.0. Like any 
other PL it’s not
perfect and it never will be, but that doesn’t bother me. 
(maybe that is because I’ve worked with many PLs, so more flexible and easier 
content with it)
I can do everything what I want Swift. I do appreciate what y’all doing.
Still, I’d hope it doesn’t go in the same direction as Java and C++ getting 
more and more
complicated with each release.. I’ve loaded a Swift BLE example.. take a look 
at one
if you can spare the time and ask yourself questions about long run 
maintainability of
large batches of Swift sources… 

So, take care, put a carton box over your display for a few days , leave your 
iPad or Phone at 
home, so you don’t walk like a zombie under a truck while looking for virtual 
Pokemon beings,
and live like it was "Party like it’s  1999”  (thanks Prince)

Dave, there is no such thing as reality or is there?  :o) 

Kind Regards

Ted

 








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

[swift-evolution] [Out of scope][Gibberish]

[Ted F.A. van Gaalen via swift-evolution]

Trivial matter, I’d say. How lucky you are:
Just be glad you’re not  Dutch living in Germany (the lady is from here), 
writing on English boards. :o)

https://www.youtube.com/watch?v=WcEFn-1uOyo 


Have a nice weekend, met vriendelijke groeten
TedvG

> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
> > wrote:
> 
> 1. “honor” is mis-spelled in “weird queen’s dialect”.

I'm sorry, but I throw an exception at this; when you say "weird queen's 
dialect" do you mean… English? I don't go around referring to the other 
variation as "weird can't spell dialect" (but maybe I should) 
The u in words like honour is what makes it pronounced like "onner" rather than 
"hone-ore", same with colour being "culler" rather than "coal-ore". Sorry but 
it really annoys me when people consider the English version of English to be 
the weird one, as the clue is literally in the name as to which version is 
correct. This is why it still galls me that the language in macOS is "British 
English" yet the other one is just "English" rather than "American English" or 
whatever, it's a hideous double standard.


That aside, I'm a strong +1 for the feature 

--

Message: 2
Date: Fri, 14 Oct 2016 16:14:01 +0200
From: Goffredo Marocchi >
To: Haravikk >
Cc: swift-evolution@swift.org , 
swift-build-...@swift.org 
Subject: Re: [swift-evolution] Proposal: Package Manager Version
Pinning
Message-ID: <5c0dd558-5031-4d9c-9444-106b2dd37...@gmail.com 
>
Content-Type: text/plain;   charset=utf-8

Let's not promote this idea English has comprehensible and easy to refer to 
pronunciation rules ;). It needs reforming :P, but let's keep it for 
English-Evolution ;).

Sent from my iPhone

> On 14 Oct 2016, at 13:42, Haravikk via swift-evolution 
> > wrote:
> 
> 
>> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
>> > wrote:
>> 
>> 1. “honor” is mis-spelled in “weird queen’s dialect”.
> 
> I'm sorry, but I throw an exception at this; when you say "weird queen's 
> dialect" do you mean… English? I don't go around referring to the other 
> variation as "weird can't spell dialect" (but maybe I should) 
> The u in words like honour is what makes it pronounced like "onner" rather 
> than "hone-ore", same with colour being "culler" rather than "coal-ore". 
> Sorry but it really annoys me when people consider the English version of 
> English to be the weird one, as the clue is literally in the name as to which 
> version is correct. This is why it still galls me that the language in macOS 
> is "British English" yet the other one is just "English" rather than 
> "American English" or whatever, it's a hideous double standard.
> 
> 
> That aside, I'm a strong +1 for the feature 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 


--

Message: 3
Date: Fri, 14 Oct 2016 09:34:10 -0500
From: Benjamin Spratling >
To: swift-evolution@swift.org 
Subject: Re: [swift-evolution] Proposal: Package Manager Version
Pinning
Message-ID: <9ef2369d-4182-4630-ba92-e037c4082...@mac.com 
>
Content-Type: text/plain; charset=us-ascii

> Let's not promote this idea English has comprehensible and easy to refer to 
> pronunciation rules ;). It needs reforming :P, but let's keep it for 
> English-Evolution ;).


+1
 Can you get me on that list?  I have a long list of bugs to report. :)

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

Re: [swift-evolution] private & fileprivate

[Ted F.A. van Gaalen via swift-evolution]

Most disturbing, 
What are you trying to achieve?

Well, I can be a little harsh at times too, perhaps at times
when I do not fully understand or misinterpret situations or people.
in that case I will admit my shortcoming and apologise if necessary.

However, you are being very negative, rude and insulting,
Btw, I also work with Smalltalk and assure that you are 
completely out of touch with the Smalltalk community
which is very friendly and social and so is the Swift community.

I see no need to further converse with you.

TedvG






> On 14 Oct 2016, at 02:14, Trans  wrote:
> 
> Sorry, that was a little harsh. I just think there are a lot of
> opinions here based on personal biases and not necessary the best
> prior experiences. If you want good OOP it is best to let people with
> *real* OOP experience, like SmallTalk, work it out.

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

Re: [swift-evolution] private & fileprivate

[Ted F.A. van Gaalen via swift-evolution]

Please do NOT drop the current distinction between *private* and *fileprivate*
as it is now in Swift 3
It is needed for correct OOP.  

As written before, but now a bit more compact, I hope:

I would like to have the inner members of a class as default private, 
(not fileprivate)  that is, that each entity inside the class body is not 
visible 
in the outer scope. not even in the same file!

I would only reveal entities of a class to the outer scope that are 
needed.there.
(as is the case with class properties in Objective-C and most other OOP 
supporting languages)

This is what I have to do now,
Each and every entity that I wish to keep hidden
I have to prefix with *private*: like in this example class: 
This is tedious and should be unnecessary.

class TG3DGauge: SCNNode
{

private var needles = [SCNNode]()
private var fmtStr = “" // private should be the default!

var value: CGFloat = 0  // access default “internal”! Visible to the 
outside world.
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

private var nodeUnitText = SCNNode()
private var nodeValueText = SCNNode()

private var valRange: ClosedRange = (0...100.0)
private var valScaleFactor: CGFloat = 1

// etc. much more stuff here and
// most of it should be private, that is
// only visible within the class body!
.
.
} // end class TG3DGauge

If I don’t specify an access modifier, then the default
for the items defined in classes is *internal*,
which means that these items are visible in the whole application source.

However, this is only desirable for items that I want to
reveal explicitly, of course. 
That is exactly why I need the *private* access modifier as it is now 
and not *fileprivate*  
So I am very glad that this access modifier *private* finally became 
available in Swift 3

In my classes, *private* is probably the most used keyword, but
*private* should be the default for entities within a class body
just like it is for entities within functions.

As far as I know, prefixing with *private* is the only solution in Swift to 
protect
functions, vars etc. in my class against unwanted access 
from the outer scope. I think this is not the way it should be. 

Making all entities in a class private prevents this.
and offers also reasonable protection against
the Fragile Base Class problem, (thanks Chris for url) :
 https://en.wikipedia.org/wiki/Fragile_base_class 


A solution for as it is now, albeit not a perfect one would be, 
to have some sort of access modifier which defines 
all items within the class to be private by default.
perhaps the keyword *closedscope* like in this example:

closedscope class TG3DGauge: SCNNode
{

var needles = [SCNNode]()  // is now private by default
var fmtStr = “"// is now private by default

public var value: CGFloat = 0 // Public!! visible outside class 
   // “fileprivate" or “internal”  can also be used.
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

var nodeUnitText = SCNNode()  // is now private by default
var nodeValueText = SCNNode() // is now private by default

//etc.


Again, for this reasons, don’t drop the distinction between
between *fileprivate* and *private* 
if this is done, there is afaics no way to protect items within a class body.
Leave it as it is now, please. (also to prevent source breaking as well)

(btw, the above TG3DGauge class is a perfect example: 
With real gauges it would not be a good idea if one can touch
the needles and gears inside the gauge’s casing,
which is exactly the case with OOP. e.g.
In my class example people would e.g. be able to set the angle
from needles (if not declared private)  directly, without updating the value.) 


TedvG
www.tedvg.com   (see my gauges from above class here)



>> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
>> > a écrit :
>> 
>> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
>>  
>> >> wrote:
> I actually consider it very lucky that most of our changes so far have 
> been fairly non-controversial. Everybody has a different idea of what 
> would make Swift a better language, and all of us well-meaning. But when 
> those ideas conflict, some group is going to end up unhappy. I'm actually 
> very glad that (a) we haven't had too many of these cases, and (b) even 
> when we have, people have been able to accept it and move on to 
> contributing to the next issue.
 
 
 Strong agreement here as well. This proposal has 

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

Hello Chris,

Thank you for updating me,
read this and other related info again thoroughly
and will act accordingly.
In the mean time I will work dynamically on dynamics :o)
Currently I suspend my topic. 
and  bring this back again much later but
then tagged with [out of scope] If this is appropriate,

Have I understood this correctly, 
Is that OK?

Ted


> On 13 Oct 2016, at 07:58, Chris Lattner <clatt...@apple.com> wrote:
> 
> 
>> On Oct 12, 2016, at 10:14 AM, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hello Austin
>> I haven’t read that from Chris - Must have overlooked it due to the shear 
>> volume on swift-evolution.
> 
> Completely understandable, I’m sure you’re not the only one who has missed 
> this. 
> 
> That said, FWIW, the goals for Swift 4 and the current planning stage are 
> spelled out in the front-page of the swift-evolution repo:
> https://github.com/apple/swift-evolution
> 
> As others’ have said, we are trying to approach the Swift 4 cycle based on 
> what we learned from Swift 2.2 and Swift 3.  
> 
> Thanks for understanding, 
> 
> -Chris
> 

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

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

Hi David, thanks for your explanation, most things are understandable. 

However, I am challenged by all this to study this subject more in detail
and come back with it later at a more convenient time. 

After all those years, now I have time for this to go in-depth, wait and see.

Met vriendelijke groeten
TedvG



> On 12 Oct 2016, at 23:38, David Hart <da...@hartbit.com> wrote:
> 
> Hi Ted,
> 
> My replies inline:
> 
>> On 12 Oct 2016, at 22:37, Ted F.A. van Gaalen <tedvgios...@gmail.com 
>> <mailto:tedvgios...@gmail.com>> wrote:
>> 
>> Hi David,
>> 
>> Thanks for your reply., OK, I think I understand. 
>> 
>> It then is a capacity problem, right?
> 
> Mainly. We lived through a few months where there was very little focus, and 
> everybody brought up all kind of ideas. It was great, but it was also very 
> chaotic. Many proposals were accepted, but the implementation for them was a 
> rush and a few couldn’t make it in the final release of Swift 3.
> 
> I think the decision of focusing releases is to improve the evolution process 
> by trying to make sure we set the right priorities and to make them 
> attainable. For example, if we do not focus on ABI stability, Swift 4 will 
> not be able to set the ABI in stone, which would disappoint many many people.
> 
>> In effect, it means restricting people from bringing perhaps very valuable 
>> (not necessarily my contributions) 
>> and essential ideas forward, which could play a crucial role improving Swift.
> 
> Not necessarily restrict. But politely ask them to keep a hold of those ideas 
> until a more appropriate phase of Swift’s development allows those kind of 
> proposals.
> 
>> I think this is a very negative aspect. surely bouncing creative people away,
>> dropping their efforts and interest here altogether. 
> 
> We try to be as kind and positive as possible as not to bounce create ideas 
> away. But I think it is also important that we explain the priorities of the 
> evolution process through time so Swift can move forward.
> 
>> The question then remains, where / when / how can one bring topics 
>> that are taking a longer stretch and are not bound to a certain release of 
>> Swift,
>> seemingly “outside” of this restriction under attention?
> 
> It all depends on the focus at the time. For example, the swift evolution 
> README states that phase 2 of Swift 4 will allow new features to be discussed 
> and implemented:
> 
> Stage 2 will commence once the implementation work on the Stage 1 features is 
> cresting, and can contain a few other large and small features. We expect 
> that stage 2 will commence some time in Spring 2017.
> 
>> if swift evolution is (currently? ) not open for new ideas/topics:
>> I thought that was the primary purpose of Swift evolution?
> 
> The purpose of Swift evolution as I understand it is to bring ideas, 
> proposals and discuss them to push Swift forward in line with the project 
> priorities at the time. You can, for example, bring new features and topics 
> forward now, but they need to concern ABI stability. For example, we are 
> looking at the remaining Generics features which will allow the Standard 
> Library to take its final form.
> 
> David.
> 
>> Kind Regards
>> Ted
>> 
>> 
>>> On 12 Oct 2016, at 21:48, David Hart <da...@hartbit.com 
>>> <mailto:da...@hartbit.com>> wrote:
>>> 
>>> Hello Ted,
>>> 
>>> Please try to understand. As Xiaodi and others have said a few times, it 
>>> has nothing to do with the topic being important or interesting. The 
>>> current phase of Swift 4’s development does not allow any extensive 
>>> discussion or review on topics which do not impact ABI stability:
>>> 
>>> Stage 1 focuses on the essentials required for source and ABI stability. 
>>> Features that don't fundamentally change the ABI of existing language 
>>> features or imply an ABI-breaking change to the standard library will not 
>>> be considered in this stage.
>>> 
>>>> On 12 Oct 2016, at 19:14, Ted F.A. van Gaalen via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> Apart from my perhaps fierce reaction, I am not aware of doing something 
>>>> wrong.
>>>> and I still find this topic very important. 
>>> 
>>> David.
>> 
> 

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

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

Hi Xiaodi,

thanks for you reply, yes, I am aware from most things you write here,
and also that what I wrote about dynamic facilities is probably not unique,
as there are so many people involved and interested etc. 

then you wrote
> … Swift 3, but the truth is that there will never be a release based on Swift 
> 3 that additionally has dynamic facilities.  

You wanna make a bet? I see that as a challenge to work this out in detail much 
further, because I am convinced that
these dynamic features in one form or another can be implemented successfully 
and add great value to Swift !
I come back with it much later when there is time, capacity and interest.

Oh, btw I still do believe in magic. Since 1950.

TedvG

  



> On 12 Oct 2016, at 23:45, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Wed, Oct 12, 2016 at 3:37 PM, Ted F.A. van Gaalen via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hi David,
> 
> Thanks for your reply., OK, I think I understand. 
> 
> It then is a capacity problem, right?
> 
> In effect, it means restricting people from bringing perhaps very valuable 
> (not necessarily my contributions) 
> and essential ideas forward, which could play a crucial role improving Swift.
> 
> I think this is a very negative aspect. surely bouncing creative people away,
> dropping their efforts and interest here altogether. 
> 
> The question then remains, where / when / how can one bring topics 
> that are taking a longer stretch and are not bound to a certain release of 
> Swift,
> seemingly “outside” of this restriction under attention?
> 
> if swift evolution is (currently? ) not open for new ideas/topics:
> I thought that was the primary purpose of Swift evolution?
> 
> Kind Regards
> Ted
> 
> [Edit: David just wrote a very nice reply, but since I'm mostly done with 
> this email, I'll send it along anyway as a companion response.]
> 
> I think this is worth a reply, if only because I think we've touched on the 
> underlying issues somewhat obliquely in the past.
> 
> It's enormously interesting to talk about important questions of language 
> design here on the list: that's why we're here. And it's been magical to see 
> that an idea written here, pitched convincingly, comes into being in the next 
> version of a programming language.
> 
> Except it's not magic. Dozens if not hundreds of people spend time thinking 
> about and debating concrete implementation details, then a group of people 
> painstakingly implements the result. During the Swift 3 time frame, the 
> illusion of magic fell apart because even some excellently pitched ideas, 
> carefully thought out, never became reality. This results in a huge loss of 
> time and effort. Everything that didn't make it into Swift 3 needs to be 
> re-evaluated to some extent because features are not designed in a vacuum and 
> must fit in with the rest of the language. The best solution for a problem 
> that we could design after the Swift 2 release would look very different from 
> the best solution that we can design now.
> 
> The point is, since nothing is really magic, we have to make a concession to 
> the reality that ideas too far from identified priorities are much less 
> likely to become part of the next release. It may be fun and creative to 
> think about how, hypothetically, one would design dynamic facilities to 
> support Swift 3, but the truth is that there will never be a release based on 
> Swift 3 that additionally has dynamic facilities. It is simply not a 
> productive use of anyone's creativity, time, or effort to imagine how that 
> might look; we're better off channeling everyone's energy towards making the 
> real, actual upcoming release of Swift even better.
> 
>> On 12 Oct 2016, at 21:48, David Hart <da...@hartbit.com 
>> <mailto:da...@hartbit.com>> wrote:
>> 
>> Hello Ted,
>> 
>> Please try to understand. As Xiaodi and others have said a few times, it has 
>> nothing to do with the topic being important or interesting. The current 
>> phase of Swift 4’s development does not allow any extensive discussion or 
>> review on topics which do not impact ABI stability:
>> 
>> Stage 1 focuses on the essentials required for source and ABI stability. 
>> Features that don't fundamentally change the ABI of existing language 
>> features or imply an ABI-breaking change to the standard library will not be 
>> considered in this stage.
>> 
>>> On 12 Oct 2016, at 19:14, Ted F.A. van Gaalen via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Apart from my perhaps fierce reaction, I am not

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

Hi David,

Thanks for your reply., OK, I think I understand. 

It then is a capacity problem, right?

In effect, it means restricting people from bringing perhaps very valuable 
(not necessarily my contributions) 
and essential ideas forward, which could play a crucial role improving Swift.

I think this is a very negative aspect. surely bouncing creative people away,
dropping their efforts and interest here altogether. 

The question then remains, where / when / how can one bring topics 
that are taking a longer stretch and are not bound to a certain release of 
Swift,
seemingly “outside” of this restriction under attention?

if swift evolution is (currently? ) not open for new ideas/topics:
I thought that was the primary purpose of Swift evolution?

Kind Regards
Ted


> On 12 Oct 2016, at 21:48, David Hart <da...@hartbit.com> wrote:
> 
> Hello Ted,
> 
> Please try to understand. As Xiaodi and others have said a few times, it has 
> nothing to do with the topic being important or interesting. The current 
> phase of Swift 4’s development does not allow any extensive discussion or 
> review on topics which do not impact ABI stability:
> 
> Stage 1 focuses on the essentials required for source and ABI stability. 
> Features that don't fundamentally change the ABI of existing language 
> features or imply an ABI-breaking change to the standard library will not be 
> considered in this stage.
> 
>> On 12 Oct 2016, at 19:14, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Apart from my perhaps fierce reaction, I am not aware of doing something 
>> wrong.
>> and I still find this topic very important. 
> 
> David.

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

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

Hello Austin
I haven’t read that from Chris - Must have overlooked it due to the shear 
volume on swift-evolution.

Note that as you can see, I have apologised to Xiaodi for being 
a bit too direct, such as perceived in your culture perhaps.

The Chinese characters should mean “respectful”” btw.

Apart from my perhaps fierce reaction, I am not aware of doing something wrong.
and I still find this topic very important. 

>> 4. read this on Swift.org <http://swift.org/>: 
>> "Proposing New Features"
>> 
>> "New features or directions for the Swift language can come from anyone with 
>> a good idea."
>> 
>> "Open discussion and iteration over the ideas in a public forum is essential 
>> to reaching the best possible solutions."
>> 
>> also 
>> 
>> "Everyone is welcome to propose, discuss, and review ideas to improve the 
>> Swift language and standard library on the swift-evolution mailing list 
>> <https://swift.org/community/#swift-evolution>.” 

> 

Kind Regards
TedvG 

> On 12 Oct 2016, at 19:00, Austin Zheng <austinzh...@gmail.com> wrote:
> 
> This is utterly ridiculous. Chris Lattner and the other core team members 
> posted repeatedly at the beginning of the Swift 3.x/4 development cycle 
> asking us expressly to keep the discussion focused on a number of specific 
> topics. Not only have you repeatedly ignored that request, now you are being 
> condescending and rude to a community member who has put in tremendous effort 
> over the last few months trying to make swift-evolution a better place. 
> Please consider whether or not disregarding the core team's wishes in this 
> matter is really the best way to show respect for the community and the 
> project.
> 
> Best regards,
> Austin
> 
> On Wed, Oct 12, 2016 at 9:54 AM, Ted F.A. van Gaalen via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Dear Xiaoid
> I still don’t agree with you, there should be some flexibility, things should 
> live
> and also, if we adhere to this list you refer to on Github, than no new
> topics would be discussable...
> I am sorry if I wrote a bit harsh to you.
> Kind Regards 
> 尊敬的
> 
> Ted
> 
>> On 12 Oct 2016, at 18:41, Xiaodi Wu <xiaodi...@gmail.com 
>> <mailto:xiaodi...@gmail.com>> wrote:
>> 
>> On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen <tedvgios...@gmail.com 
>> <mailto:tedvgios...@gmail.com>> wrote:
>> Hi Xiaodi,
>> please read in-line, thank you.
>> 
>>> On 12 Oct 2016, at 15:58, Xiaodi Wu <xiaodi...@gmail.com 
>>> <mailto:xiaodi...@gmail.com>> wrote:
>>> 
>>> On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen <tedvgios...@gmail.com 
>>> <mailto:tedvgios...@gmail.com>> wrote:
>>> 
>>>> On 11 Oct 2016, at 23:04, Xiaodi Wu <xiaodi...@gmail.com 
>>>> <mailto:xiaodi...@gmail.com>> wrote:
>>>> 
>>>> Reflection is likely to be tackled in Swift 5, no?
>>> 
>>> I'd think you don’t need reflection that much, because defining
>>> dynamic classes (and other entities) are solely incremental compiler
>>> tasks, for which it can use  previously compiled meta reference
>>> information (xref symbols etc). 
>>> 
>>> Imho in that perspective it is more or less independent
>>> of reflection. Reflection is as far as I can see is more intended to offer 
>>> meta information at the programming level.? 
>>> 
>>>> So realistically, this could be on track for Swift 6 or 7.
>>> 
>>> As already written, there is no timeframe/deadline for this idea, it is 
>>> just an idea, 
>>> not a proposal (yet).
>>> 
>>>> Let's postpone discussion until then.
>>> 
>>> Feel free to do so, but why postponing having ideas and discussing them?
>>> 
>>> The core team has requested that discussions be focused on the priorities 
>>> identified for the current phase of Swift 4. There's a sound rationale for 
>>> this request. Per Chris: "The community benefits from keeping focus on a 
>>> limited number of topics, because if there is too much going on, no one can 
>>> follow and keep track of it all.  It is important for the core team to be 
>>> involved in key discussions up front.  In the Swift 3 cycle, it was 
>>> problematic that many folks had no time to follow the threads until after 
>>> the review period completed.”
>> 
>> You are pulling the above out of context hereunder: 
>>> 
>

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

Dear Xiaoid
I still don’t agree with you, there should be some flexibility, things should 
live
and also, if we adhere to this list you refer to on Github, than no new
topics would be discussable...
I am sorry if I wrote a bit harsh to you.
Kind Regards 
尊敬的

Ted

> On 12 Oct 2016, at 18:41, Xiaodi Wu  wrote:
> 
> On Wed, Oct 12, 2016 at 11:32 AM, Ted F.A. van Gaalen  > wrote:
> Hi Xiaodi,
> please read in-line, thank you.
> 
>> On 12 Oct 2016, at 15:58, Xiaodi Wu > > wrote:
>> 
>> On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen > > wrote:
>> 
>>> On 11 Oct 2016, at 23:04, Xiaodi Wu >> > wrote:
>>> 
>>> Reflection is likely to be tackled in Swift 5, no?
>> 
>> I'd think you don’t need reflection that much, because defining
>> dynamic classes (and other entities) are solely incremental compiler
>> tasks, for which it can use  previously compiled meta reference
>> information (xref symbols etc). 
>> 
>> Imho in that perspective it is more or less independent
>> of reflection. Reflection is as far as I can see is more intended to offer 
>> meta information at the programming level.? 
>> 
>>> So realistically, this could be on track for Swift 6 or 7.
>> 
>> As already written, there is no timeframe/deadline for this idea, it is just 
>> an idea, 
>> not a proposal (yet).
>> 
>>> Let's postpone discussion until then.
>> 
>> Feel free to do so, but why postponing having ideas and discussing them?
>> 
>> The core team has requested that discussions be focused on the priorities 
>> identified for the current phase of Swift 4. There's a sound rationale for 
>> this request. Per Chris: "The community benefits from keeping focus on a 
>> limited number of topics, because if there is too much going on, no one can 
>> follow and keep track of it all.  It is important for the core team to be 
>> involved in key discussions up front.  In the Swift 3 cycle, it was 
>> problematic that many folks had no time to follow the threads until after 
>> the review period completed.”
> 
> You are pulling the above out of context hereunder: 
>> 
>> I'm sure many people have ideas about dynamic facilities in Swift, as do we 
>> all about other ideas, and many have been trying to be respectful of this 
>> new proposed process. I think we can all agree that maximum participation 
>> and the best solutions are most likely when everyone stays on the same page 
>> with regard to the process by which we go about these discussions. No need 
>> to postpone having ideas about Swift or talking about them with your friends 
>> and colleagues, but let's respect the core team's urging to postpone 
>> discussing them on this particular list for the reasons identified above.
>> 
> 
> 1.  You are not a member of the core team, far from it, sorry.
>  Don’t think for them, they can do that quite well themselves. and thus: 
> 
> I'm not trying to speak for the core team; sorry if I'm giving off that 
> impression.
>  
> 2.  If the core team would have problems with me bringing forward this topic, 
>   they might/will inform me that this is undesired, in that case I’ll 
> stop writing about it. 
> 
> As a member of the community, I'm voicing *my* concern that this is not an 
> opportune time to discuss this topic. It's up to all participants, not just 
> the core team, to try to make sure that the evolution process works 
> effectively. So far, in the context of other threads, other community members 
> have also been active in pointing out when topics stray too far from the 
> suggested areas of focus. I think this is good practice and I'm trying to 
> contribute to that effort.
> 
> 3. My current subject is an extension spin-off from the topic “associated 
> objects”, wherein
> “extending the language" is discussed. Meta Programming and Adding 
> Dynamic Features to Swift 
> are currently strongly in focus and is surely one of the most important 
> things to bring to Swift in the near future!
> 
> I'm sorry, but this is not true. The list of focus topics for this phase of 
> Swift is on the swift-evolution GitHub project readme, and this is not one of 
> them.
> 
> 4. read this on Swift.org : 
> "Proposing New Features"
> 
> "New features or directions for the Swift language can come from anyone with 
> a good idea."
> 
> "Open discussion and iteration over the ideas in a public forum is essential 
> to reaching the best possible solutions."
> 
> also 
> 
> "Everyone is welcome to propose, discuss, and review ideas to improve the 
> Swift language and standard library on the swift-evolution mailing list 
> .” 
> 
> 
> 
> 5. If a certain topic is not interesting for you personally then simply 
> ignore it and don’t react.
> 
> That is not 

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

Hi Xiaodi,
please read in-line, thank you.

> On 12 Oct 2016, at 15:58, Xiaodi Wu  wrote:
> 
> On Wed, Oct 12, 2016 at 7:47 AM, Ted F.A. van Gaalen  > wrote:
> 
>> On 11 Oct 2016, at 23:04, Xiaodi Wu > > wrote:
>> 
>> Reflection is likely to be tackled in Swift 5, no?
> 
> I'd think you don’t need reflection that much, because defining
> dynamic classes (and other entities) are solely incremental compiler
> tasks, for which it can use  previously compiled meta reference
> information (xref symbols etc). 
> 
> Imho in that perspective it is more or less independent
> of reflection. Reflection is as far as I can see is more intended to offer 
> meta information at the programming level.? 
> 
>> So realistically, this could be on track for Swift 6 or 7.
> 
> As already written, there is no timeframe/deadline for this idea, it is just 
> an idea, 
> not a proposal (yet).
> 
>> Let's postpone discussion until then.
> 
> Feel free to do so, but why postponing having ideas and discussing them?
> 
> The core team has requested that discussions be focused on the priorities 
> identified for the current phase of Swift 4. There's a sound rationale for 
> this request. Per Chris: "The community benefits from keeping focus on a 
> limited number of topics, because if there is too much going on, no one can 
> follow and keep track of it all.  It is important for the core team to be 
> involved in key discussions up front.  In the Swift 3 cycle, it was 
> problematic that many folks had no time to follow the threads until after the 
> review period completed.”

You are pulling the above out of context hereunder: 
> 
> I'm sure many people have ideas about dynamic facilities in Swift, as do we 
> all about other ideas, and many have been trying to be respectful of this new 
> proposed process. I think we can all agree that maximum participation and the 
> best solutions are most likely when everyone stays on the same page with 
> regard to the process by which we go about these discussions. No need to 
> postpone having ideas about Swift or talking about them with your friends and 
> colleagues, but let's respect the core team's urging to postpone discussing 
> them on this particular list for the reasons identified above.
> 
1.  You are not a member of the core team, far from it, sorry.
 Don’t think for them, they can do that quite well themselves. and thus: 

2.  If the core team would have problems with me bringing forward this topic, 
  they might/will inform me that this is undesired, in that case I’ll stop 
writing about it. 

3. My current subject is an extension spin-off from the topic “associated 
objects”, wherein
“extending the language" is discussed. Meta Programming and Adding Dynamic 
Features to Swift 
are currently strongly in focus and is surely one of the most important 
things to bring to Swift in the near future!

4. read this on Swift.org : 
"Proposing New Features"

"New features or directions for the Swift language can come from anyone with a 
good idea."

"Open discussion and iteration over the ideas in a public forum is essential to 
reaching the best possible solutions."

also 

"Everyone is welcome to propose, discuss, and review ideas to improve the Swift 
language and standard library on the swift-evolution mailing list 
.” 



5. If a certain topic is not interesting for you personally then simply ignore 
it and don’t react.

6. Well meant advice: be a little less lofty,
 

Kind Regards 
TedvG


> In this case for instance, thinking about dynamic facilities, will presumably 
> also influence thinking about reflection and vice versa. 
> Thinking “wider” and “further” broadens the horizon of course.
> For example. what about a compiler/interpreter self improving based on 
> artificial intelligence? is this 2016? 
> So one can (should) do both: that is think in small steps, like discussing
> “just”  language elements and at the same time have an eye (or two) for the 
> broader picture. If one concentrates too much on the direct path in front, 
> one might
> not see other paths or what lays further ahead, which limits progress. 
> 
> 
> Let me write a small cartoon here, just intended as a little bit of humour 
> just to illustrate this:
> 
> A few thousand years ago, two very nice beings ( just returned from attending 
> a
> very primitive and awkward election debate, still shivering),  looking at a 
> pair 
> of fairly round stone slabs with a hole in the centre.
> 
> “What’s this ?, Why round? why the holes? Nice job, but what is it? Is it 
> art?”
> 
> “Ehmm, well.. I might call it ‘Wheelz', not sure yet, you can use two of 
> more of them
> underneath or aside of things you’d like to move around more easily…
> with less friction, which was a hell of a drag anyway."
> 

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

> On 11 Oct 2016, at 23:04, Xiaodi Wu  wrote:
> 
> Reflection is likely to be tackled in Swift 5, no?

I'd think you don’t need reflection that much, because defining
dynamic classes (and other entities) are solely incremental compiler
tasks, for which it can use  previously compiled meta reference
information (xref symbols etc). 

Imho in that perspective it is more or less independent
of reflection. Reflection is as far as I can see is more intended to offer 
meta information at the programming level.? 

> So realistically, this could be on track for Swift 6 or 7.

As already written, there is no timeframe/deadline for this idea, it is just an 
idea, 
not a proposal (yet).

> Let's postpone discussion until then.

Feel free to do so, but why postponing having ideas and discussing them? 
In this case for instance, thinking about dynamic facilities, will presumably 
also influence thinking about reflection and vice versa. 
Thinking “wider” and “further” broadens the horizon of course.
For example. what about a compiler/interpreter self improving based on 
artificial intelligence? is this 2016? 
So one can (should) do both: that is think in small steps, like discussing
“just”  language elements and at the same time have an eye (or two) for the 
broader picture. If one concentrates too much on the direct path in front, one 
might
not see other paths or what lays further ahead, which limits progress. 


Let me write a small cartoon here, just intended as a little bit of humour just 
to illustrate this:

A few thousand years ago, two very nice beings ( just returned from attending a
very primitive and awkward election debate, still shivering),  looking at a 
pair 
of fairly round stone slabs with a hole in the centre.

“What’s this ?, Why round? why the holes? Nice job, but what is it? Is it art?”

“Ehmm, well.. I might call it ‘Wheelz', not sure yet, you can use two of 
more of them
underneath or aside of things you’d like to move around more easily…
with less friction, which was a hell of a drag anyway."

The other guy walks around it, apparently deeply thinking about it. 
after some silence he says:
“Aha… hmm.. well.. Oh, i see, yeah, yep, that’s kinda cool.. might be useful. 
But let’’s postpone discussing it until  ball-bearings have been invented. “


hmmm, I really have too much time… :o)

Kind Regards
Ted



 






> 
> 
> On Tue, Oct 11, 2016 at 15:59 David Sweeris via swift-evolution 
> > wrote:
> 
> On Oct 11, 2016, at 12:40, Anton Zhilin via swift-evolution 
> > wrote:
> 
>> Hello Ted,
>> First of all, this topic belongs to reflection, which is specifically stated 
>> to be out of scope of Swift 4 Phase 1. So all considerations are purely 
>> theoretical for now.
>> That said, I also thought about this problem. The best I could imagine is 
>> something along the following lines:
>> 
>> var builder = StructBuilder(name: "Person")
>> builder.addProperty(name: "name", type: String.self)
>> builder.addProperty(name: "age", type: Int.self)
>> builder.addComputedProperty(name: "description", getter: { (this: Any) -> 
>> String in ... })
>> builder.addComformance(CustomStringConvertible.self)
>> let type: Any.Type = builder.build()
>> Obviously, to interact with such dynamic types and their objects, we need 
>> the whole working reflection system that we don’t have right now.
>> 
> 
> I *think* that's only true for non-generic code, and types that aren't 
> subclasses... I think...
> 
> Anyway, I'm starting to wonder if some code I'm trying to write might be 
> impossible without either this feature, or some/all of the stuff from the 
> generics manifesto. So put me down as, in principle, a strong +1 (pending 
> details of the proposal when it actually gets written for Swift 10).
> 
> - 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] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

Hi Jeremy
> On 12 Oct 2016, at 10:52, Jeremy Pereira <jeremy.j.pere...@googlemail.com> 
> wrote:
> 
> 
>> On 11 Oct 2016, at 14:15, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>> While Swift is mainly a statically typed language, recompilation or 
>> additional 
>> compilation and somehow link it al together is obviously necessary at run 
>> time, 
>> each time a dynamic structure is defined. 
>> Because of this, it will most probably have performance drawbacks 
>> at run time
> 
> Not the least of which would be the need to install a Swift compiler 
> toolchain on the target Mac - or iOS device.
Yes that is true. Or at least a smaller more specialized  part of it that can 
do dynamic additions/plug-in…
TedvG



 
 

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

Re: [swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

thank you, Goffredo, Anton, see inline
TedvG
> On 11 Oct 2016, at 21:10, Goffredo Marocchi  wrote:
> 
> I quite like your builder pattern way of adding properties and methods :).
> 
> Sent from my iPhone
> 
> On 11 Oct 2016, at 19:40, Anton Zhilin via swift-evolution 
> > wrote:
> 
>> Hello Ted,
>> First of all, this topic belongs to reflection, which is specifically stated 
>> to be out of scope of Swift 4 Phase 1. So all considerations are purely 
>> theoretical for now.
>> 
The idea is not intended to be in a deadline/timeframe
could be Swift 7 for that :o) 
>> ..  That said, I also thought about this problem. The best I could imagine 
>> is something along the following lines:
>> 
>> var builder = StructBuilder(name: "Person")
>> builder.addProperty(name: "name", type: String.self)
>> builder.addProperty(name: "age", type: Int.self)
>> builder.addComputedProperty(name: "description", getter: { (this: Any) -> 
>> String in ... })
>> builder.addComformance(CustomStringConvertible.self)
>> let type: Any.Type = builder.build()
>> Obviously, to interact with such dynamic types and their objects, we need 
>> the whole working reflection system that we don’t have right now.
>> 
>> 
I don’t know how much reflection is needed in this context.
-Adding dynamic classes can be solved with incremental? recompiling 
based on previously generated compiler reference metadata, 
already present. (note that in debug mode there already is a lot of “reflection”
available)
 - static entities defined at the initial compilation
 - and cumulative for dynamic entities when additionaly compiled at run time.
As soon as a dynamically defined or redefined class (or struct) is compiled
it is then regarded as a static type, transparent to the application thus which 
instances 
cannot be dynamically altered, because they are “tied” to the class definition.
Instance creation is then the same as with statically defined classes

(but all this  is a bit simplified of course, and I don’t know much about 
compilers.
Maybe similar to Smalltalk where methods/classes are precompiled separately)

@ Chris: As a Compiler Pro could you say more about this and about the whole 
idea, Chris? 

Thanks
TedvG




>> Dynamic Class/Struct Definition At Run Time 
>> 
>> At the time of this writing, 11 October 2016, it is not possible to define 
>> arbitrary 
>> classes, structs and maybe other entities dynamically at run time in Swift. 
>> I have some idea about it, expressed in this message.
>> 
>> Creating class and other types dynamically should be as simple and as easy 
>> to understand 
>> as possible, preferably with nearly the same style and syntax as the 
>> "regular" declarations,
>>  leaving things like "Meta""Type" T.Self etc. as transparent as possible. 
>> That should in this context be "under the hood", as it is also the case 
>> when defining static classes. 
>> 
>> I have constructed the following (hypothetical) example code,
>>  which serves as just a "thinking model", so to speak.
>> 
>> // In this example we dynamically create and use 
>> // an example class named "Monolith"
>> // First, we declare an "empty dynamic class"
>> // (a slot) at compile time, that is later defined at run time.
>>
>> dynamic class Monolith // defined later just this line.
>> 
>> // Use a constructor that accepts 
>> // a string which contains a class definition, 
>> // exactly like one would define a class in Swift statically. 
>> // with the exception that name of the class is not specified. 
>> // It is replaced by placeholder, an underscore, because 
>> // the class name itself is inferred when declaring it. 
>> // Specifying the class name will throw an error.
>> 
>> var classDefStr = 
>> "class _ :SCNNode, AnInterface, AnotherInterface "+
>> "{var l = 9.0; var h = 4.0; var  w = 1.0; " +
>> "var color = UIColor.blue;"+ 
>> "func volume() -> Double { return l * w * h} “ +
>> aStringWithAdditionalComponentDefinitions + "}"
>> 
>> // Of course, this class definition string can also be assembled
>> // completely programatically, read from a file or database, etc. 
>> 
>> func defMonolithClass()
>> {
>> do  // try to define a class, NOT an instance.
>> {
>> try Monolith = 
>> Meta.defineClass(withString: classDefStr)
>> }
>> catch Meta.classDefinitionError
>> {
>> // handle a possible class dynamic compilation errors
>> // e.g. syntax errors. symbols not found etc.  
>> }
>> catch Meta.classCreationConflict
>> {
>> // class cannot be redefined 
>> // when instances of Monolith still exist.
>> // This restriction is probably necessary.
>> // Also, static classes 

[swift-evolution] Dynamic Class/Struct Definition At Run Time

[Ted F.A. van Gaalen via swift-evolution]

Dynamic Class/Struct Definition At Run Time 

At the time of this writing, 11 October 2016, it is not possible to define 
arbitrary 
classes, structs and maybe other entities dynamically at run time in Swift. 
I have some idea about it, expressed in this message.

Creating class and other types dynamically should be as simple and as easy to 
understand 
as possible, preferably with nearly the same style and syntax as the "regular" 
declarations,
 leaving things like "Meta""Type" T.Self etc. as transparent as possible. 
That should in this context be "under the hood", as it is also the case 
when defining static classes. 

I have constructed the following (hypothetical) example code,
 which serves as just a "thinking model", so to speak.

// In this example we dynamically create and use 
// an example class named "Monolith"
// First, we declare an "empty dynamic class"
// (a slot) at compile time, that is later defined at run time.
   
dynamic class Monolith // defined later just this line.

// Use a constructor that accepts 
// a string which contains a class definition, 
// exactly like one would define a class in Swift statically. 
// with the exception that name of the class is not specified. 
// It is replaced by placeholder, an underscore, because 
// the class name itself is inferred when declaring it. 
// Specifying the class name will throw an error.

var classDefStr = 
"class _ :SCNNode, AnInterface, AnotherInterface "+
"{var l = 9.0; var h = 4.0; var  w = 1.0; " +
"var color = UIColor.blue;"+ 
"func volume() -> Double { return l * w * h} “ +
aStringWithAdditionalComponentDefinitions + "}"

// Of course, this class definition string can also be assembled
// completely programatically, read from a file or database, etc. 

func defMonolithClass()
{
do  // try to define a class, NOT an instance.
{
try Monolith = 
Meta.defineClass(withString: classDefStr)
}
catch Meta.classDefinitionError
{
// handle a possible class dynamic compilation errors
// e.g. syntax errors. symbols not found etc.  
}
catch Meta.classCreationConflict
{
// class cannot be redefined 
// when instances of Monolith still exist.
// This restriction is probably necessary.
// Also, static classes defined at compile time
// cannot be redefined
}

// After successfully declaring our dynamic class,
// we can now add more features to it, like 
// properties and dynamic extensions. (It is not
// possible of course to add statically defined extensions
// and protocols to a non-existing dynamic class at compile time.
// neither is it possible to do this at run time.)

do 
{  
try Meta.addPropertyTo(Monolith,"mass",3.4)
try Meta.addPropertyTo(Monolith,"physics", PhysicsBody)
try Meta.addExtensionTo(Monolith, someExtensionDefStr)
}
catch Meta.classExtenderError
{
// handle the error
}
catch Meta.classCreationConflict
{
// class definition cannot be altered 
// when instances of Monolith (still) exist.
// This restriction seems to be necessary.
// Also, static classes defined at compile time
// cannot be extended dynamically. 
}
}

...

defMonolithClass()

// After having dynamically declared the example class,
// we can produce instances of it, like with any 
// other class. It throws an error
// when the dynamic class has not been defined. 


public let monolith = Monolith() 

let vol = monolith.volume

monolith = nil  // remove instance(s), pre ARC when we wish to 
// redefine it. 

defMonolithClass()  // redefine it, possibly with other definition 
parameters as in the first definition in this example.

   

Some examples for additional functionality

let Bird: DynamicClass?


Bird = Meta.defineClass(withString: classDefStr)

Bird = Meta.defineClass(superClass: StaticClass | DynamicClass,
interfaces: [Protocol],
  definitionString: classItemsDefStr)

Bird = Meta.defineCopyOfClass(class: StaticClass| DynamicClass,
  append: classItemsDefString)



Meta.addpropertyTo(Monolith, 
   name:"mass",initializeWith: 3.4, type: Float) 

Meta.addPropertyTo(Monolith,
name "Person",initializeWith: someValue, type: Inferred) 

Meta.addConstantPropertyTo(Monolith,
name "cow",initializeWithString: aString, 
type: FourLeggedAnimal) 




In principle, variants of this 

Re: [swift-evolution] associated objects

[Ted F.A. van Gaalen via swift-evolution]

Hi Chris
I am a bit slow to respond, please read inline, thanks.
> On 1 Oct 2016, at 01:47, Chris Lattner <clatt...@apple.com> wrote:
> 
> On Sep 30, 2016, at 2:51 PM, Ted F.A. van Gaalen via swift-evolution 
> <swift-evolution@swift.org> wrote:

>> Is it possible to have best of (these completely different) both worlds? 
> 

> Yes, of course it is.  

> Your email spends a lot of words
Does it? 

> trying to form a false dichotomy.
Well, sorry, thank you. but No, I don’t think so: 
I am merely describing the advantages and 
disadvantages of static programming languages. 
It doesn’t mean it should be one or the other, just observing.
Just thinking about the future in years, not in weeks. 
Even so, I still like Swift.

> Swift can definitely have both awesome dynamic features while still having 
> performance, predictability and safety.
Yes, I take it that it is possible to implement these. 
Currently it is not possible to do meta programming in Swift, that is, create 
arbitrary functions, properties and new classes
during run time. hypothetical along the lines as if it were so:

// Warning! hypothetical as yet not compilable coding follows:

let Monolith: Class?

var classdefstring = "parentclass: SpaceObject;" +
"var l = 9.0; var h = 4.0; var  w = 1.0; " +
"var color = " + defaultMonolithColorStr   +
";func volume() -> Double { return l * w * h} “ +
aStringWithAdditionalComponentDefinitions

func defMonolithClass()
{
do  // try to define a class, NOT an instance.
{
try Monolith = Meta.defineClass(classdefstring)
}
catch Meta.classDefinitionError
{
// handle a possible class definition error
// e.g. syntax errors. symbols not found etc.  
}
catch Meta.creationConflict
{
// class cannot be defined or redefined when instances of Monolith 
exist.
// necessary?
}

do  // dynamically add components to the Monolith
{
try Meta.addPropertyTo( Monolith,"mass",3.4)
try Meta.addPropertyTo( Monolith,"physics", PhysicsBody)
try Meta.addFunctionTo( Monolith, someFunctionDefinitionString)
}
catch Meta.ClassExtenderError
{
// handle the error
}
catch Meta.creationConflict
{
// class definition cannot be altered when instances of Monolith 
exist.
// necessary? 
}
}

defMonolithClass()

// Make an instance of the dynamically generated class
public let mn = Monolith() 

let vol = mn.volume

// One can remove after usage, normally ARC should take care of that.
// unless one would wish to reinstate/redefine Monolith again.
mn = nil   // remove instance

Monolith = nil  // should throw an error when instances of Monolith are 
still around.

defMonolithClass()  // again, possibly with other definition strings 

// Of course ARC should remove dynamic class defs automagically when no 
longer
// needed. 

There could be overloads of defining classes etc. using other methods than 
string wise declaration.. 
Of course, Meta… for defining structs and other components could be made in a 
similar fashion.
I’d guess  that it might be very hard and complicated to implement meta 
creation similar to the above? 
Probably needed the app to interact many times with a compiler present on the 
target OS/device? - 
thereby making small pluggable “bricks”  
Just brainstorming here: I know nearly nothing of compiler construction.

> 
>> Would it be possible in Swift to have facilities to generate objects 
>> dynamically at runtime? and, if desirable, how can such be implemented?
> 
> Here’s an extant implementation that you can use today:
> https://github.com/Zewo/Reflection <https://github.com/Zewo/Reflection>
Very complex code (to me, hard to read) . As far as I can see, it’s a clever 
hack but vulnerable because 
depending completely on the underlying memory occupation and layout of an 
existing class definition?  
Totally new classes/structs etc. cannot be defined with it?
(like in the above hypothetical class def example)

> 
> I’m sure it isn’t ideal, but it proves that it can be done.  When we have 
> bandwidth to reevaluate this area from first principles, I’m sure we can make 
> improvements on it.
Yeah, I guess it can be done, that would be great!
> 
> I will grant you that Smalltalk is a beautiful language in its simplicity, 
> but for that simplicity it makes many tradeoffs that we’re not willing to 
> make.  
The only tradeoffs I can think of so far are:

  - Run time speed. in spite of precompiled methods etc Smalltalk is not so 
fast as compiled statical 
p

Re: [swift-evolution] associated objects

[Ted F.A. van Gaalen via swift-evolution]

> What it does is allow developers to extend the language to do things that it 
> doesn't support. 


Hitting boundaries... or so it seems... This is very interesting. 
In spite of its very modern approach, wether we like it or not, Swift is 
still a conventional Hard Coded Statical Programming Language,
 (here further in this text referred to as HCSPL) 
which means that, like in C++ or C# etc. its language 
elements are essentially predefined, "fixed", and that 
it is therefore a daunting task to make the language as 
versatile as possible and to satisfy everyone's requirements, 
We can see that every day in swift-evolution and for that matter 
all other HCSPL (C#, C++, Python, ObjC etc) related forums.

HCSPL are in a sense a traditional compromise to "The Machine” 
and enables us -within the limitations  of our current state of main 
stream technology- to make highly optimised fast running compiled applications. 
That we know is the virtue of hard coded static languages. 
"The Machine" however gets more advanced and faster day by day 
thereby diminishing the need for HCSPL in its course. 

However, (as far as I know) , due to the nature of HCSPL, like Swift, 
there is no (direct and supported and convenient) way supporting 
meta-programming facilities, e.g. to generate define objects (classes), 
and its instances on the fly, that is, at run time. 

In most cases, one can live with this HCSPL "compromise", especially with 
Swift, 
which is very flexible and offers many convenient ways to solve a wide spectrum 
of programming challenges. However, one could think of many applications like
 in AI where applications can improve and extend themselves, learning to adjust 
and adapt to their environment, thereby altering and tuning its performance, 
like our brains do...naturally. 
In contrast, a HCSPL forces one to match one's problem solving to the language 
elements that are available in the HCSPL. In a sense it's like having a big box 
with Lego bricks, that is predefined discrete elements, which allow one to 
build things 
with it, however it still remains limited as Lego. 
This is not the case with a dynamic language like Smalltalk.

Since ca 1980 I have a high interest in Smalltalk (and other OOP dynamic
programming languages too). Some would argue that Smalltalk is a 
programming language, but take a closer look, (e.g. with Pharo).
It is just a relatively small set of mainly syntactic rules defining the 
environment wherein the Smalltalk system lives (almost literally) as a 
dynamic object hierarchy, were everything is an object, which as we know 
is a completely different approach compared to HCSPLs.

Before Swift had arrived, my hope was that the successor of Objective C 
would be Smalltalk, or at least Smalltalk  as a breeding environment for 
developing macOS, iOS, tvOS and watchOS applications. In this role it would then
be desirable that the apps thus produced are "closed apps" so to speak, that is 
that 
the development environment  is not available to the end-user. 
The thought of a e.g. "new Xcode/Smalltalk" being the next Apple development 
environment seemed reasonable, also because ObjectiveC had features 
inspired by Smalltalk. (as all OOP languages have) 
Alas, it didn't happen..but I keep dreaming... 

Perhaps out of context, one then might ask how to interface that 
Xcode/Smalltalk to all those existing libraries (Cocoa UIKit etc.) 
This can be done by letting Smalltalk crawl through all API definitions,
generating its own interface classes dynamically. This sounds ambitious 
but it can be done. Something  a HCSPL like Swift could never do as it is. 

And now we don't have Smalltalk but instead Swift, not bad at all, currently 
I find it the most advanced HCSPL now available.  

However, my verbose text here could be food for thoughts: 

Is it possible to have best of (these completely different) both worlds? 
Would it be possible in Swift to have facilities to generate objects 
dynamically at runtime? and, if desirable, how can such be implemented?


Kind Regards
TedvG

> On Sep 30, 2016, at 9:40 AM, Jay Abbott  > wrote:

> 

> Robert,

> 

> What it does is allow developers to extend the language to do things that it 
> doesn't support. Associated Objects is just a flexible way to allow 
> developers to do that, and that's how I used it in Objective-C, so that's 
> what I thought of in Swift when I found that "I want to do  but the 
> language doesn't support it". Maybe there's a completely different way to 
> achieve the same thing - but I just went with what I know.


"I want to do  but the language doesn't support it” is the whole reason for 
this list!  I want to know what “” is in order to wrap my head around your 
proposal better. I’m not here to invalidate your work with a slew of 
criticisms, I’m just trying to understand your proposal by probing you about it.


> So it's difficult to come up with concrete examples of "things a 

Re: [swift-evolution] class/struct inner member access scope classifier

[Ted F.A. van Gaalen via swift-evolution]

Hi Jeremy and Nevin

Sorry for the delay. quite busy.

As described, the point of my message is that I would like to have the inner 
members of a class
as default private, that is, not visible in the outer scope and to reveal 
members (entities)
of the class to the outside world *explicitly* by specifying an access 
qualifier like
“public” or “internal”, so exactly the other way round as it is now. 
In the current situation I have to precede all declarations which I don’t want 
to reveal
with “private”. Usually most entities of a class should not be visible outside 
of it. 
To prevent source breaking one could precede the class definition with a 
keyword, telling
Swift that all members of a class are private by default like so

closedscope class TG3DGauge: SCNNode
{

var needles = [SCNNode]()  // is now private by default
var fmtStr = “"// is now private by default

public var value: CGFloat = 0 // Public!! visible outside class also for 
“fileprivate" or “internal”  

(as written before)  

If this “closedscope” qualifier is not used things are exactly as it is now.

The “fileprivate” qualifier doen’t need to go so no source breaking here.
I simply stated that I am not really a fan of it.

Kind Regards
Ted



> On 27 Sep 2016, at 10:34, Jeremy Pereira <jeremy.j.pere...@googlemail.com> 
> wrote:
> 
> 
>> On 26 Sep 2016, at 20:58, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Hello! Hope you are all OK! 
>> 
>> 
>> As far as I can see without binoculars, the “fileprivate” acces modifier
>> could be dropped, were it not for source compatibility reasons... 
>> 
>> Unless I am missing something: 
> 
> Yes you are missing something. I, for example have a few cases where it is 
> useful. On the other hand, I was against the change in the meaning of private 
> but, I have to concede that the new meaning is useful. 
> 
> As for dropping file private, why? You don’t have to use it if you don’t want 
> to, so it’s not hurting you. On the other hand, I can use it when I deem it 
> to be the right thing to do. 
> 
> 
>> I don’t want the inner elements
>> of a class (or struct ?) to be visible in outer scope!
>> This is the default case in most OOP languages. 
> 
> The default in Java is package scope. I’m not sure what the default in C++ 
> is, but it’s not private, ditto Javascript. So while that might not be most 
> OOP languages, it probably covers most OOP programs.
> 
> While I think private by default has merit, we are where we are.
> 
> 

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

[swift-evolution] class/struct inner member access scope classifier

[Ted F.A. van Gaalen via swift-evolution]

Hello! Hope you are all OK! 

Using and converting To Swift 3.0 with many advantages
and very little problems.OK, thanks to all !
also for the reasonably smart converter. Yes, yes, yes, I’m
still missing the classical for ;; loop (don’t wake me up 
again plse :o)  but overall it is quite good!

I also value the -finally correct- meaning of the scope qualifier “private” , 
thanks, 
which is as it should be (imho) inner scope restricting. 

As for “fileprivate”: as yet, I haven’t found a case
where I should use “fileprivate” also because to me, the contents of
a file should in principle not have anything to do with the entities
contained in it, as a file should be just an data carrier. Therefore, 
it should have no effect to wether or not concatenate source.swift files
into one big file for example, although I would not recommend this.

As far as I can see without binoculars, the “fileprivate” acces modifier
could be dropped, were it not for source compatibility reasons... 
  
Unless I am missing something: 
Still. something is not quite right yet, I think.
Just like in a Swift function, I don’t want the inner elements
of a class (or struct ?) to be visible in outer scope!
This is the default case in most OOP languages. 
I fail to understand why this is not so in Swift, please enlighten me. 

As it is now, and as far as I know, I have to explicitly
declare *all* entities inside a class that should not be accessible
outside the class as private, like in this real-world example:  


class TG3DGauge: SCNNode
{

private var needles = [SCNNode]()
private var fmtStr = “" // private should be the default imho.

var value: CGFloat = 0
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

private var nodeUnitText = SCNNode()
private var nodeValueText = SCNNode()

private var valRange: ClosedRange = (0...100.0)

var rangeNeedlesActive: Bool = true
{
didSet
{
needles[2].isHidden = !rangeNeedlesActive
needles[3].isHidden = !rangeNeedlesActive
}
}

private var valScaleFactor: CGFloat = 1

// etc. more stuff
.
.
} // end class TG3DGauge


It should (imho) be the other way around: that every member of 
a class is private by default - that is invisible outside the scope 
were it is declared in. This was (and still is) the case with Objective C,
where you need to explicitly declaring them in  the  sourcefile.h file
to make them visible and accessible in the outer scope 
Everything else, as existing in the sourcefile.m remains hidden, not visible
in the outer scope.

As a solution/suggestion and also to prevent the gruesome
horror (did i already wrote something about that?  :o) of source breaking.
I could think of the “closedscope” (or some other word) 
access modifier, which states that all things declared inside a class, 
are private within the class and thus invisible in the outer scope, unless
preceeded with an overriding acces scope modifier like “public", “internal" or 
"fileprivate” 



closedscope class TG3DGauge: SCNNode
{

var needles = [SCNNode]()  // is now private by default
var fmtStr = “"// is now private by default

public var value: CGFloat = 0 // Public!! visible outside class also for 
“fileprivate" or “internal”  
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

var nodeUnitText = SCNNode()  // is now private by default
var nodeValueText = SCNNode() // is now private by default

//etc.

This “closedscope" modifier should only be effective for the current class, not 
its superclass(es),
allowing one to hide/reveal entities in each class independently being part of 
the hierarchy.
Also entities declared private should not be visible in descendant classes

Also please note that I do miss the “protected” scope access modifier which 
allows entities to be exclusively
visible to descendant classes, as in Java. Why not implement it in Swift as 
well?  

AFAICS:  All mentioned here would not be a source breaking. 

Opinions, remarks welcome.

met vriendelijke groeten
Ted








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

Re: [swift-evolution] Multi dimensional - iterator, Iterator2D, Iterator3D

[Ted F.A. van Gaalen via swift-evolution]

t()
>if values[i] != nil {
>return thisValue
>} else if i == 0 {
>done = true
>return thisValue
>} else {
>iterators[i] = args[i].makeIterator()
>values[i] = iterators[i].next()
>i -= 1
>}
>} while true
>}
> }
> 
> func cartesianProduct<U, V where U: Sequence, V == U.Iterator.Element>(_ a: 
> U, _ b: U, _ c: U) ->
>AnyIterator<(V, V, V)>
> {
>    var subIterator: AnyIterator<[V]> = cartesianProduct(a, b, c)
>return AnyIterator() {
>if let value = subIterator.next() {
>return (value[0], value[1], value[2])
>}
>return nil
>}
> }

Kind Regards
Ted



> Garth
> 
>> 
>>> 
>>> On Jul 30, 2016, at 1:48 PM, Ted F.A. van Gaalen via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> 
>>> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>> 
>>> wrote:
>>> 
>>>> Hi Chris,
>>>> 
>>>> thanks for the tip about Hirundo app!
>>>> 
>>>> A positive side-effect of removing the classical for;; loop
>>>> (yes, it’s me saying this :o)  is that it forces me to find
>>>> a good and generic equivalent for it, 
>>>> making the conversion of my for;;s to 3.0 easier.
>>>> which is *not* based on collections or sequences and
>>>> does not rely on deeper calls to Sequence etc.
>>>> 
>>>> so, I’ve made the functions [iterator, iterator2D, iterator3D]  (hereunder)
>>>> wich btw clearly demonstrate the power and flexibility of Swift. 
>>>> 
>>>> Very straightforward, and efficient (i assume) just like the classical 
>>>> for;; loop.  
>>>> It works quite well in my sources.
>>>> 
>>>> As a spin-off,  I’ve extended these to iterators for matrices 2D and 
>>>> cubes? 3D...
>>>> 
>>>> Question: 
>>>> Perhaps implementing “multi dimensional iterator functions
>>>> in Swift might  be a good idea. so that is no longer necessary to 
>>>> nest/nest/nest iterators. 
>>>> 
>>>> Met vriendelijke groeten, sorry for my “intensity” in discussing the 
>>>> classical for;; 
>>>> I'll have to rethink this for;; again..  
>>>> Thanks, Ted.
>>>> 
>>>> Any remarks ( all ), suggestions about the code hereunder:  ? 
>>>> 
>>>> protocol NumericType
>>>> {
>>>>func +(lhs: Self, rhs: Self) -> Self
>>>>func -(lhs: Self, rhs: Self) -> Self
>>>>func *(lhs: Self, rhs: Self) -> Self
>>>>func /(lhs: Self, rhs: Self) -> Self
>>>>func %(lhs: Self, rhs: Self) -> Self
>>>> }
>>>> 
>>>> extension Double : NumericType { }
>>>> extension Float  : NumericType { }
>>>> extension CGFloat: NumericType { }
>>>> extension Int: NumericType { }
>>>> extension Int8   : NumericType { }
>>>> extension Int16  : NumericType { }
>>>> extension Int32  : NumericType { }
>>>> extension Int64  : NumericType { }
>>>> extension UInt   : NumericType { }
>>>> extension UInt8  : NumericType { }
>>>> extension UInt16 : NumericType { }
>>>> extension UInt32 : NumericType { }
>>>> extension UInt64 : NumericType { }
>>>> 
>>>> 
>>>> /// Simple iterator with generic parameters, with just a few lines of code.
>>>> /// for most numeric types (see above)
>>>> /// Usage Example:
>>>> ///
>>>> ///   iterate(xmax, { $0 > xmin}, -xstep,
>>>> ///{x in
>>>> ///print("x = \(x)")
>>>> ///return true  // returning false acts like a break
>>>> /// } )
>>>> ///
>>>> ///  -Parameter vstart: Initial value
>>>> ///  -Parameter step:The iteration stepping value.
>>>> ///  -Parameter test:A block with iteration test. e.g. {$0 > 10}
>>>> ///
>>>> ///  -Parameter block:   A block to be executed with each step.
>>>> ///   The block must include a return true (acts like "continue")
>>>> ///   or false (acts like "break")
>>>> ///  -Please Note: 
>>>> ///  

Re: [swift-evolution] [swift-users] Multi dimensional - iterator, Iterator2D, Iterator3D

[Ted F.A. van Gaalen via swift-evolution]

g 
>> SE-0045.  Once that's done, you can  combine `sequence(first:, next:)` and 
>> `prefix(while:)` to into a single function `sequence(first:, next:, while:)` 
>> like this:
>> 
>> public func sequence(first: T, next: (T) -> T?, while test: (T) -> Bool) 
>> -> UnfoldSequence<T, UnfoldSequence<T, (T?, Bool)>> {
>> return sequence(first: first, next: next).prefix(while: test)
>> }
>> 
>> The combined sequence/prefix call allows you to create loops like this:
>> 
>> for outerIndex in sequence(first: 1, next: { $0 * 2 }, while: { $0 <= 64 }) {
>> for innerIndex in sequence(first: 1, next: { $0 * 2 }, while: { $0 <= 64 
>> }) {
>> print(outerIndex, innerIndex)
>> }
>> }
>> 
>> These loops can be nested. break and continue work.  You can use tuples for 
>> multiple arguments. While I'd like to see a combined form adopted into Swift 
>> 4b (the deferred "sugar"), it isn't a high priority.
>> 
>> -- E
>> 
>> 
>>> On Jul 31, 2016, at 7:18 AM, Ted F.A. van Gaalen via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
>>>> On 31.07.2016, at 04:28, jaden.gel...@gmail.com 
>>>> <mailto:jaden.gel...@gmail.com> wrote:
>>>> 
>>>> What benefit do Iterator2D and Iterator3D provide that nesting does not?
>>> Hi Jaden,
>>> well, simply because of hiding/enclosing repetitive functionality
>>> like with every other programming element is convenient,
>>> prevents errors and from writing the same over and over again.
>>> That is why there are functions.
>>> but you already know that, of course.
>>> Kind Regards
>>> TedvG
>>> 
>>>> 
>>>> On Jul 30, 2016, at 1:48 PM, Ted F.A. van Gaalen via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>>> Hi Chris,
>>>>> 
>>>>> thanks for the tip about Hirundo app!
>>>>> 
>>>>> A positive side-effect of removing the classical for;; loop
>>>>>  (yes, it’s me saying this :o)  is that it forces me to find
>>>>> a good and generic equivalent for it, 
>>>>> making the conversion of my for;;s to 3.0 easier.
>>>>> which is *not* based on collections or sequences and
>>>>> does not rely on deeper calls to Sequence etc.
>>>>> 
>>>>> so, I’ve made the functions [iterator, iterator2D, iterator3D]  
>>>>> (hereunder)
>>>>> wich btw clearly demonstrate the power and flexibility of Swift. 
>>>>> 
>>>>> Very straightforward, and efficient (i assume) just like the classical 
>>>>> for;; loop.  
>>>>> It works quite well in my sources.
>>>>> 
>>>>> As a spin-off,  I’ve extended these to iterators for matrices 2D and 
>>>>> cubes? 3D...
>>>>> 
>>>>> Question: 
>>>>> Perhaps implementing “multi dimensional iterator functions
>>>>> in Swift might  be a good idea. so that is no longer necessary to 
>>>>> nest/nest/nest iterators. 
>>>>> 
>>>>> Met vriendelijke groeten, sorry for my “intensity” in discussing the 
>>>>> classical for;; 
>>>>> I'll have to rethink this for;; again..  
>>>>> Thanks, Ted.
>>>>> 
>>>>> Any remarks ( all ), suggestions about the code hereunder:  ? 
>>>>> 
>>>>> protocol NumericType
>>>>> {
>>>>> func +(lhs: Self, rhs: Self) -> Self
>>>>> func -(lhs: Self, rhs: Self) -> Self
>>>>> func *(lhs: Self, rhs: Self) -> Self
>>>>> func /(lhs: Self, rhs: Self) -> Self
>>>>> func %(lhs: Self, rhs: Self) -> Self
>>>>> }
>>>>> 
>>>>> extension Double : NumericType { }
>>>>> extension Float  : NumericType { }
>>>>> extension CGFloat: NumericType { }
>>>>> extension Int: NumericType { }
>>>>> extension Int8   : NumericType { }
>>>>> extension Int16  : NumericType { }
>>>>> extension Int32  : NumericType { }
>>>>> extension Int64  : NumericType { }
>>>>> extension UInt   : NumericType { }
>>>>> extension UInt8  : NumericType { }
>&

Re: [swift-evolution] Multi dimensional - iterator, Iterator2D, Iterator3D

[Ted F.A. van Gaalen via swift-evolution]

> On 31.07.2016, at 04:28, jaden.gel...@gmail.com wrote:
> 
> What benefit do Iterator2D and Iterator3D provide that nesting does not?
Hi Jaden,
well, simply because of hiding/enclosing repetitive functionality
like with every other programming element is convenient,
prevents errors and from writing the same over and over again.
That is why there are functions.
but you already know that, of course.
Kind Regards
TedvG

> 
> On Jul 30, 2016, at 1:48 PM, Ted F.A. van Gaalen via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> Hi Chris,
>> 
>> thanks for the tip about Hirundo app!
>> 
>> A positive side-effect of removing the classical for;; loop
>>  (yes, it’s me saying this :o)  is that it forces me to find
>> a good and generic equivalent for it, 
>> making the conversion of my for;;s to 3.0 easier.
>> which is *not* based on collections or sequences and
>> does not rely on deeper calls to Sequence etc.
>> 
>> so, I’ve made the functions [iterator, iterator2D, iterator3D]  (hereunder)
>> wich btw clearly demonstrate the power and flexibility of Swift. 
>> 
>> Very straightforward, and efficient (i assume) just like the classical for;; 
>> loop.  
>> It works quite well in my sources.
>> 
>> As a spin-off,  I’ve extended these to iterators for matrices 2D and cubes? 
>> 3D...
>> 
>> Question: 
>> Perhaps implementing “multi dimensional iterator functions
>> in Swift might  be a good idea. so that is no longer necessary to 
>> nest/nest/nest iterators. 
>> 
>> Met vriendelijke groeten, sorry for my “intensity” in discussing the 
>> classical for;; 
>> I'll have to rethink this for;; again..  
>> Thanks, Ted.
>> 
>> Any remarks ( all ), suggestions about the code hereunder:  ? 
>> 
>> protocol NumericType
>> {
>> func +(lhs: Self, rhs: Self) -> Self
>> func -(lhs: Self, rhs: Self) -> Self
>> func *(lhs: Self, rhs: Self) -> Self
>> func /(lhs: Self, rhs: Self) -> Self
>> func %(lhs: Self, rhs: Self) -> Self
>> }
>> 
>> extension Double : NumericType { }
>> extension Float  : NumericType { }
>> extension CGFloat: NumericType { }
>> extension Int: NumericType { }
>> extension Int8   : NumericType { }
>> extension Int16  : NumericType { }
>> extension Int32  : NumericType { }
>> extension Int64  : NumericType { }
>> extension UInt   : NumericType { }
>> extension UInt8  : NumericType { }
>> extension UInt16 : NumericType { }
>> extension UInt32 : NumericType { }
>> extension UInt64 : NumericType { }
>> 
>> 
>> /// Simple iterator with generic parameters, with just a few lines of code.
>> /// for most numeric types (see above)
>> /// Usage Example:
>> ///
>> ///   iterate(xmax, { $0 > xmin}, -xstep,
>> ///{x in
>> ///print("x = \(x)")
>> ///return true  // returning false acts like a break
>> /// } )
>> ///
>> ///  -Parameter vstart: Initial value
>> ///  -Parameter step:The iteration stepping value.
>> ///  -Parameter test:A block with iteration test. e.g. {$0 > 10}
>> ///
>> ///  -Parameter block:   A block to be executed with each step.
>> ///   The block must include a return true (acts like "continue")
>> ///   or false (acts like "break")
>> ///  -Please Note: 
>> ///  There is minor precision loss ca: 1/1000 ... 1/500 
>> ///  when iterating with floating point numbers.
>> ///  However, in most cases this can be safely ignored.
>> ///  made by ted van gaalen.
>> 
>> 
>> func iterate (
>> vstart:  T,
>>_ vstep:  T,
>>_  test: (T) -> Bool,
>>_ block: (T) -> Bool )
>> {
>> var current = vstart
>> 
>> while test(current) && block(current)
>> {
>> current = current + vstep
>> }
>> }
>> 
>> 
>> /// X,Y 2D matrix (table) iterator with generic parameters
>> func iterate2D (
>>  xstart:  T,  _ xstep: T, _ xtest: (T) -> Bool,
>>_ ystart:  T,  _ ystep: T, _ ytest: (T) -> Bool,
>>_ block: (T,T) -> Bool )
>> {
>> var xcurrent = xstart
>> var ycurrent = ystart
>> 
>> var dontStop = true
>> 
>> while xtest(xcurrent) && dontStop
>> {
>> ycurrent

Re: [swift-evolution] Multi dimensional - iterator, Iterator2D, Iterator3D

[Ted F.A. van Gaalen via swift-evolution]

> On 31.07.2016, at 07:07, Chris Lattner  wrote:
> 
> 
>> On Jul 30, 2016, at 1:48 PM, Ted F.A. van Gaalen  
>> wrote:
>> 
>> Hi Chris,
>> 
>> thanks for the tip about Hirundo app!
>> 
>> A positive side-effect of removing the classical for;; loop
>> (yes, it’s me saying this :o)  is that it forces me to find
>> a good and generic equivalent for it, 
>> making the conversion of my for;;s to 3.0 easier.
>> which is *not* based on collections or sequences and
>> does not rely on deeper calls to Sequence etc.
> 
> Hi Ted,
> 
> I know that you’re very passionate about the removal of C style for loops,

Hi Chris,

I am trying to channel my sometimes chaotic energy into positive things,
which means I should not have only criticism, but try
to find positive alternatives and suggestions for the things 
that I don’t like.

> but any direction to add back features to compensate for them will need to 
> wait until Stage 2 of Swift 4’s planning cycle.
Yes, of course, I understand that. Forgot to mention that.
It is more intended as to viewing aspects of iteration in general.

The code example was initially intended as a convenience “workaround” 
(usable without any alterations in Swift 2.x and higher) 
for those of us who are using the for;; frequently,

However, I for me find it now even better then just a workaround 
especially for 2 and 3D iterations. 

So it could be that I won’t miss the for;; that much as I thought.
as the power and  flexibility of Swift mostly allows us to add 
own extensions as alternative solutions when desired
and that is very cool!

Kind Regards
TedvG

(Note that that my biggest challenge in life is to coordinate 
the chaos that always storms in my mind due to heavy 
ADHD aspects (which also have advantages)
and to communicate with “other lifeforms”  
like human beings because of that.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Multi dimensional - iterator, Iterator2D, Iterator3D

[Ted F.A. van Gaalen via swift-evolution]

Hi Chris,

thanks for the tip about Hirundo app!

A positive side-effect of removing the classical for;; loop
 (yes, it’s me saying this :o)  is that it forces me to find
a good and generic equivalent for it, 
making the conversion of my for;;s to 3.0 easier.
which is *not* based on collections or sequences and
does not rely on deeper calls to Sequence etc.

so, I’ve made the functions [iterator, iterator2D, iterator3D]  (hereunder)
wich btw clearly demonstrate the power and flexibility of Swift. 

Very straightforward, and efficient (i assume) just like the classical for;; 
loop.  
It works quite well in my sources.

As a spin-off,  I’ve extended these to iterators for matrices 2D and cubes? 
3D...

Question: 
Perhaps implementing “multi dimensional iterator functions
in Swift might  be a good idea. so that is no longer necessary to 
nest/nest/nest iterators. 

Met vriendelijke groeten, sorry for my “intensity” in discussing the classical 
for;; 
I'll have to rethink this for;; again..  
Thanks, Ted.

Any remarks ( all ), suggestions about the code hereunder:  ? 

protocol NumericType
{
func +(lhs: Self, rhs: Self) -> Self
func -(lhs: Self, rhs: Self) -> Self
func *(lhs: Self, rhs: Self) -> Self
func /(lhs: Self, rhs: Self) -> Self
func %(lhs: Self, rhs: Self) -> Self
}

extension Double : NumericType { }
extension Float  : NumericType { }
extension CGFloat: NumericType { }
extension Int: NumericType { }
extension Int8   : NumericType { }
extension Int16  : NumericType { }
extension Int32  : NumericType { }
extension Int64  : NumericType { }
extension UInt   : NumericType { }
extension UInt8  : NumericType { }
extension UInt16 : NumericType { }
extension UInt32 : NumericType { }
extension UInt64 : NumericType { }


/// Simple iterator with generic parameters, with just a few lines of code.
/// for most numeric types (see above)
/// Usage Example:
///
///   iterate(xmax, { $0 > xmin}, -xstep,
///{x in
///print("x = \(x)")
///return true  // returning false acts like a break
/// } )
///
///  -Parameter vstart: Initial value
///  -Parameter step:The iteration stepping value.
///  -Parameter test:A block with iteration test. e.g. {$0 > 10}
///
///  -Parameter block:   A block to be executed with each step.
///   The block must include a return true (acts like "continue")
///   or false (acts like "break")
///  -Please Note: 
///  There is minor precision loss ca: 1/1000 ... 1/500 
///  when iterating with floating point numbers.
///  However, in most cases this can be safely ignored.
///  made by ted van gaalen.


func iterate (
vstart:  T,
   _ vstep:  T,
   _  test: (T) -> Bool,
   _ block: (T) -> Bool )
{
var current = vstart

while test(current) && block(current)
{
current = current + vstep
}
}


/// X,Y 2D matrix (table) iterator with generic parameters
func iterate2D (
 xstart:  T,  _ xstep: T, _ xtest: (T) -> Bool,
   _ ystart:  T,  _ ystep: T, _ ytest: (T) -> Bool,
   _ block: (T,T) -> Bool )
{
var xcurrent = xstart
var ycurrent = ystart

var dontStop = true

while xtest(xcurrent) && dontStop
{
ycurrent = ystart
while ytest(ycurrent) && dontStop
{
dontStop = block(xcurrent, ycurrent)
ycurrent = ycurrent + ystep
}
xcurrent = xcurrent + xstep
}
}


/// X,Y,Z 3D (cubic) iterator with generic parameters:

func iterate3D (
xstart:  T,  _ xstep: T, _ xtest: (T) -> Bool,
  _ ystart:  T,  _ ystep: T, _ ytest: (T) -> Bool,
  _ zstart:  T,  _ zstep: T, _ ztest: (T) -> Bool,
  _ block: (T,T,T) -> Bool )
{
var xcurrent = xstart
var ycurrent = ystart
var zcurrent = zstart

var dontStop = true

while xtest(xcurrent) && dontStop
{
ycurrent = ystart
while ytest(ycurrent) && dontStop
{
zcurrent = zstart
while ztest(zcurrent) && dontStop
{
dontStop = block(xcurrent, ycurrent, zcurrent)
zcurrent = zcurrent + zstep
}
ycurrent = ycurrent + ystep
}
xcurrent = xcurrent + xstep
}
}


func testIterator()
{
iterate(0.0, 0.5, {$0 < 1000.0} ,
{ value in
print("Value = \(value) ")
return true
} )

let startv: CGFloat = -20.0
let stepv: CGFloat =   0.5

iterate(startv, stepv, {$0 < 1000.0} ,
{ val in
print("R = \(val)")
return true
} )

let tolerance = 0.01 // boundary tolerance for floating point type

iterate2D( 0.0, 10.0, { $0 < 100.0 + tolerance } ,
   0.0,  5.0, { $0 <  50.0 + tolerance } ,
   {x,y in
print("x = \(x) y = \(y)")
return true  // false from block stops 

Re: [swift-evolution] End of source-breaking changes for Swift 3

[Ted F.A. van Gaalen via swift-evolution]

Hi Taras,

There’s more than enough evidence in the whole programming world
to justify the existence of the classical for loop, also in Swift!
Not only in “old” languages, for instance, take a look in Go. 
Excellent implementation there of the for;;

https://tour.golang.org/flowcontrol/1 <https://tour.golang.org/flowcontrol/1>


Btw, to me, It’s not a matter of “defeat” or “winning”.

I am not the only person preferring the for;; to stay.

I’ve also written about other things, like comma less parameter list etc.

But I will not continue this discussion right now and wait til August.

Kind Regards
TedvG

> On 29.07.2016, at 00:30, Taras Zakharko <taras.zakha...@uzh.ch> wrote:
> 
> 
>> On 29 Jul 2016, at 00:21, Saagar Jha via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> The reason C-style for loops were removed were because most of the time they 
>> could be represented by Swift syntax. Have you taken a look at 
>> stride(from:to:by:)?
Yes I did. 
> 
> A minor correction: it should be ‚all of the time‘ :) Iterator-based loops 
> are a strict superset of the for(;;) loop.
No. the for;; is much more versatile and easier to use, but I’v already wrote 
much about this. 
> 
> Anyway, we have discussed this extensively in the past, Ted is the only 
> person who’s still keeps stubbornly hacking on this topic and so far he has 
> failed to produce any convincing evidence in favour of the for(;;) loop.
Please read it again.
> Its time to either accept defeat or produce some new material to discuss. 
> Austin is absolutely right that repeating same things only makes this already 
> huge list even bigger and less digestible. 
> 
> Best, 
> 
>  T. 
> 
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Jul 28, 2016, at 15:08, Ted F.A. van Gaalen via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Hi Austin,
>>> 
>>> please read inline.
>>>> On 28.07.2016, at 23:47, Austin Zheng <austinzh...@gmail.com 
>>>> <mailto:austinzh...@gmail.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Thu, Jul 28, 2016 at 2:37 PM, Ted F.A. van Gaalen 
>>>> <tedvgios...@gmail.com <mailto:tedvgios...@gmail.com>> wrote:
>>>> Hi Austin, thank you, please see inline
>>>> ? 
>>>> I have explained this many times before, didn’t I? 
>>>> 
>>>> Its removal causes a very crucial limitation/change in the way 
>>>> one writes programs, So writing about this for;; subject is
>>>> very, very different from long discussions like those about 
>>>> allowing a comma at the end of a list or not…
>>>> because removing the for;; has a very heavy impact.
>>>> 
>>>> Furthermore, IMHO the decision to remove the for;; was based
>>>> on very subjective loose and partly irrelevant criteria.
>>>> 
>>>> 
>>>> I don't care how good your reasons are, the fact of the matter is that it 
>>>> was extensively discussed, a decision was made, and it is now a done deal.
>>> Napoleon said something similar when pushing his army towards Moscow...
>>>> Please remember that these are high-traffic lists that many people 
>>>> subscribe to; complaining about the C for loop is a waste of everybody's 
>>>> time.
>>> That’s your opinion.
>>>> At the very least, please respect the process and put together a proposal 
>>>> that we can all discuss,
>>> As written before, I will write the proposal after Swift 3.0 is released.
>>> If you are interested in bringing it back then you could help
>>> me with it.
>>>> instead of asking Chris or whoever to step in and make an exception 
>>>> because you don't like it.
>>> Yes, indeed, I am exceptionally asking to make an exception, to keep the 
>>> for ;; in
>>> for the time being.
>>> 
>>> As concerning your “high traffic” notion, this is written material
>>> no doubt, the recipients are capable enough to put it aside for later
>>> if they’d wish to do so. 
>>> 
>>> Sorry, if you don’t like it.
>>> Thanks.
>>> TedvG
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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] End of source-breaking changes for Swift 3

[Ted F.A. van Gaalen via swift-evolution]

Hi Ross,
> On 29.07.2016, at 00:21, Ross O'Brien  wrote:
> 
> 
> This would imply, that if a decision is made, which in a later and changed 
> context proves to be a bad one, would be irreversible? 
> Better turn half way than to err in continuing.
> Or, one decides to go diving, but arriving at the location, notice that the 
> water is full of sharks? Still continue? 
> 
> 
> But there's no 'continue' here. The time to 'turn half way' was months ago. 
> We already arrived.
> 
> We moved house. We sold the old one, handed over the keys, moved into the new 
> place and put up the wallpaper. If you want to move back to the old house, 
> you'll need to convince everyone to put everything back into boxes.
Hey Ross, look around you in the house!  Ah, there it is! 
You’d only have to unpack the box with the for;; it’s still there :o)
I bet, the components in the compiler to process a for;; are still present in 
the 3.0 compiler
and could be simply reactivated?


> 
> Swift 3 does not have C-style for-loops. That decision has been made.


> 
> But on August 1, feel free to make a pitch explaining why C-style for-loops 
> are a feature worth adding to Swift 4.
Will do. thanks.

Anyway:
I’ll drop the subject for now, also
because my highly exceptional request will  probably not be honored.
Then so be it. 
Met vriendelijke groeten
Ted
> 

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

Re: [swift-evolution] End of source-breaking changes for Swift 3

[Ted F.A. van Gaalen via swift-evolution]

Hi Austin,

please read inline.
> On 28.07.2016, at 23:47, Austin Zheng  wrote:
> 
> 
> 
> On Thu, Jul 28, 2016 at 2:37 PM, Ted F.A. van Gaalen  > wrote:
> Hi Austin, thank you, please see inline
> ? 
> I have explained this many times before, didn’t I? 
> 
> Its removal causes a very crucial limitation/change in the way 
> one writes programs, So writing about this for;; subject is
> very, very different from long discussions like those about 
> allowing a comma at the end of a list or not…
> because removing the for;; has a very heavy impact.
> 
> Furthermore, IMHO the decision to remove the for;; was based
> on very subjective loose and partly irrelevant criteria.
> 
> 
> I don't care how good your reasons are, the fact of the matter is that it was 
> extensively discussed, a decision was made, and it is now a done deal.
Napoleon said something similar when pushing his army towards Moscow...
> Please remember that these are high-traffic lists that many people subscribe 
> to; complaining about the C for loop is a waste of everybody's time.
That’s your opinion.
> At the very least, please respect the process and put together a proposal 
> that we can all discuss,
As written before, I will write the proposal after Swift 3.0 is released.
If you are interested in bringing it back then you could help
me with it.
> instead of asking Chris or whoever to step in and make an exception because 
> you don't like it.
Yes, indeed, I am exceptionally asking to make an exception, to keep the for ;; 
in
for the time being.

As concerning your “high traffic” notion, this is written material
no doubt, the recipients are capable enough to put it aside for later
if they’d wish to do so. 

Sorry, if you don’t like it.
Thanks.
TedvG



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

Re: [swift-evolution] End of source-breaking changes for Swift 3

[Ted F.A. van Gaalen via swift-evolution]

Thanks, Chris.
> On 28.07.2016, at 22:56, Chris Lattner  wrote:
> 
> 
>> On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen  
>> wrote:
>>> The Swift team at Apple has reflected on this and decided what it "means" 
>>> for Swift 3 to be source compatible with Swift 4 and later releases going 
>>> forward. Our goal is to allow app developers to combine a mix of Swift 
>>> modules (e.g., SwiftPM packages), where each module is known to compile 
>>> with a specific version of the language (module A works with Swift 3, 
>>> module B works with Swift 3.1, etc.), then combine those modules into a 
>>> single binary. The key feature is that a module can be migrated from Swift 
>>> 3 to 3.1 to 4 (and beyond) independently of its dependencies.
>> 
>> This sounds like a reasonable solution...
>> If I understand you correctly;
>>   The compiler(s)  would be able to compile sources from 3.0 and future 
>> versions?
> 
> Correct.
> 
>> Unfortunately that doesn’t go back to 2.2, 
> 
> Correct - this doesn’t apply to Swift 2.2 or Swift 2.3.  Source compatibility 
> will start with Swift 3, just like we’ve been saying for some time now.
> 
> -Chris
> 

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

Re: [swift-evolution] End of source-breaking changes for Swift 3

[Ted F.A. van Gaalen via swift-evolution]

> On 28.07.2016, at 20:20, Karl Wagner <razie...@gmail.com> wrote:
> 
> +1. There have been lots of accepted proposals which I argued against, but 
> community-driven evolution means we have to compromise.
This would imply, that if a decision is made, which in a later and changed 
context proves to be a bad one, would be irreversible? 
Better turn half way than to err in continuing.
Or, one decides to go diving, but arriving at the location, notice that the 
water is full of sharks? Still continue? 

> 
> In Plato's Crito, Socrates refuses to flee Athens after being sentenced to 
> death. He entered in to an agreement with the state to participate in the 
> process and respect its judgements, and reasons that to violate the rules of 
> the system because he believes the outcome unjust would be a greater 
> injustice.
> 
> Just mentioning it; it's always been a fascinating story to me.
Thanks, interesting. Long ago I’ve read a bit in Plato - The Republic but was 
back then
to hyper active to concentrate..
> 
> Karl
> 
> Sent from my new Email 
> <https://itunes.apple.com/app/apple-store/id922793622?pt=814382=8=my_new_email>
> 
TedvG
> 
>> On Jul 28, 2016 at 7:33 PM, > <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>   -= Maybe it’s not too late =- 
>>> For the moment the classical for ;;  could simply 
>>> remain activated  (Yes)  in 3.0. because:  
>> 
>> I don't understand why you keep on complaining about this.
>> 
>> For the record, I too think getting rid of the C-style for loop was a 
>> mistake, and there are a number of other proposals whose outcomes are not 
>> ones I would have personally preferred.
>> 
>> However,
>> 
>> 1. There is a well-defined process through which all changes to the Swift 
>> language must go, laid out in the swift-evolution repository's documentation 
>> from the first day Swift became an open-source project.
>> 2. That process includes feedback and review from both the community and the 
>> Swift core engineers, and often multiple rounds of discussion.
>> 3. The process doesn't work if we disregard its outcomes simply because we 
>> don't like them, or if we allow interminable chains of back-and-forth 
>> proposals because people on one side of issue X simply cannot accept a 
>> particular decision.
>> 
>> The technical aspects of the C-style for loop and its proposed replacements 
>> have already been discussed ad nauseam on this list and in other places, so 
>> I won't touch on them.
>> 
>> Best regards,
>> Austin  
>> 
>>>   
>>>   - It doesn’t conflict at all with all other language elements,
>> 
>> ___ swift-evolution mailing list 
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <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] End of source-breaking changes for Swift 3

[Ted F.A. van Gaalen via swift-evolution]

Hi Austin, thank you, please see inline.
> On 28.07.2016, at 19:33, Austin Zheng <austinzh...@gmail.com> wrote:
> 
> 
>> On Jul 28, 2016, at 10:19 AM, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>   -= Maybe it’s not too late =- 
>> For the moment the classical for ;;  could simply 
>> remain activated  (Yes)  in 3.0. because:  
> 
> I don't understand why you keep on complaining about this.
? 
I have explained this many times before, didn’t I? 

Its removal causes a very crucial limitation/change in the way 
one writes programs, So writing about this for;; subject is
very, very different from long discussions like those about 
allowing a comma at the end of a list or not…
because removing the for;; has a very heavy impact.

Furthermore, IMHO the decision to remove the for;; was based
on very subjective loose and partly irrelevant criteria.

For example the suggestion, that experienced
programmer will refrain from using the for;;
was ridiculous. It’s a bit like assuming that a technicians
will not use a screw drivers anymore..

I’ve wrote about this extensively before.
 
Just read that proposal to remove 
the for;; and for that matter also the ++ and — again.. 
Albeit a bit understandable: It was one of the first proposals, 
written in a time when everything had just started..

Personally, for my apps, removing the for;; results in lots of 
otherwise unnecessary time converting at least ten source files, 
typically containing about five for;; loops each, nested ones also. 

Automagic conversion is not possible also because many of 
these iterations are with floating point numbers and also 
run backwards.let alone with decrementing steps.

In my Apple TV 3D SceneKit based app under construction
these are for;; with floats, which have to be replaced by do-while constructs..

In all of my apps (i am a pour lonesome developer :o) 
I have to test all of this again and again to make sure 
my apps work flawlessly without errors again, as they do now.
(see RavelNotes and RavelNotesBasic) 
These apps are quite complex, changing and testing
these is not that easy.

Ergo:  as a law of steel: 
One should *never* introduce backward breaking changes!

So I am very glad Ted Kremenek came forward with this
module based different version compilation option.
It seems to be a reasonable alternative. 

If not, I would have dropped Swift soon and look for another
solution to produce my apps. However, this would be very regrettable.
because I really love Swift. I wouldn’t be here if I didn’t !

I was quite happy with Swift 2. It had all the things I tend to expect
from a state of the art programming language. very cool.
and also eagerly waiting for *additive* changes and improvements.


@Craig: 
When Swift was presented and its use encouraged by you, Craig, on the WWDC, 
it was not supposed to be in a *beta stage* ! At least, it was my impression
that it was no longer in beta stage and that it was OK to use Swift for
production, no one told otherwise, if I remember correctly.

And so I embraced Swift immediately, me being mostly an early adapter 
  (even when being in IT since 1978 or so, or maybe rather because of that!) 
 assuming that it was solid and a safe bet to use it in a production 
environment. 

However, IMHO, it has been virtually in a beta stage until now, 
simply because, things were and are still changing!.
Yes, of course I do expect improvements, however they should be
additive, not code breaking changes.

I also do understand and don’t underestimate the motion with new languages. 


If I had known all this before, I would have remained programming
my apps in Objective C until a more solid version came along. 
In the mean time, yes, of course, I would have played with it and studying it
sideways, and take part and listening in this forum. 

And, maybe then I would have enough faith in 3.0 that is to 
use Swift 3.0 and higher fully in a production environment.
And don’t get me wrong, I like Swift very much it really 
is a very advanced development.

And then another thing, well, maybe you’d
think that I am whining a bit, but try to see it this way:
Most things in Swift are OK and even superb, so I don’t
need to write about these! What remains then is just to 
write about the thing’s I don’t like or which could be
improved. This might give the impression that I am just 
complaining, note however, nothing is farther from the truth. 

( because we just write, which is a very limited form
of human communication being a lot different then sitting
around a round table (hmm that reminds me of something :o)
laughing and drinking coffee. I you’d wish to change that
send me a ticket to San Francisco or so. :o) 


> 
> For the record, I too think getting rid of the C-style for loop was a mistake,
Yes it is. Well, then maybe you also could perhaps have made 

[swift-evolution] End of source-breaking changes for Swift 3

[Ted F.A. van Gaalen via swift-evolution]

Hi Ted ! 

Thanks guys for all for the hard work! 
What you wrote makes sense, is a relief, and gives me faith in Swift’s future!

> The Swift team at Apple has reflected on this and decided what it "means" for 
> Swift 3 to be source compatible with Swift 4 and later releases going 
> forward. Our goal is to allow app developers to combine a mix of Swift 
> modules (e.g., SwiftPM packages), where each module is known to compile with 
> a specific version of the language (module A works with Swift 3, module B 
> works with Swift 3.1, etc.), then combine those modules into a single binary. 
> The key feature is that a module can be migrated from Swift 3 to 3.1 to 4 
> (and beyond) independently of its dependencies.

This sounds like a reasonable solution...
If I understand you correctly;
   The compiler(s)  would be able to compile sources from 3.0 and future 
versions?

well, that solves most source breaking issues, 

It then has however the disadvantage that one cannot
combine older  language elements from 
e.g. version 3.0  and 4.0 or higher together in a single source file? 
However, if so, I can live with that.

Does this method have further compatibility issues that at the moment don’t 
cross my mind?

Unfortunately that doesn’t go back to 2.2, unfortunately
because in 3.0 the classical for ; ; loop will be deactivated.

I regard this as a serious mistake and 
have no doubt this removal is disturbing many 
experienced and more pragmatical programmers.

It made my alarm bells ringing and it was the main 
reason I have climbed in to Swift-Evolution
to discuss this.

  -= Maybe it’s not too late =- 
For the moment the classical for ;;  could simply 
remain activated  (Yes)  in 3.0. because:  
  
  - It doesn’t conflict at all with all other language elements,

  - most important: there are still no good alternative for iterations like 
these  
   for var x:Float = -60;x < 60;x += w * 1.2
   {
   for var y: Float = 130;y > 60;y -= backtrack
  // etc.
  // especially for iterations using Floating point numbers!

 for these, one has to fall back on tedious do-while constructs.

  - There are more sane reasons, but a few months ago
 I have written extensively about this subject.

So, yes, obviously my recommendation is 

Please don’t remove the for ;; from 3.0
 
and replace the current compile cry:
“C-style for statement is deprecated and will be removed in a future 
version of Swift”

which I currently perceive like this:

   “ The for ;; statement, although being used successfully in many other 
languages
  is in conflict with the attitude and believe of some of us with a lot of 
theoretical experience.
 Therefore it will be removed in a future version of Swift. 
 Please resort to using the do-while statement instead.”

the new compiler warning could be then:
  “Warning! This for ;; statement should only be used by highly  skilled 
   programmers with a more pragmatical attitude.
   Use at your own risk, like with any other Swift statement.” 

Just leave it in.  (but I guess it could be to late) 

If it is really removed in 3.0, then I promise I will write
an official  proposal to bring it back in 3.x and further.
some help with that is appreciated.


Kind Regards

Yet another Ted :o) 

www.tedvg.com 





> Date: Wed, 27 Jul 2016 12:38:51 -0700
> From: Ted Kremenek >
> To: swift-evolution@swift.org , 
> swift-evolution-annou...@swift.org 
> ,
>   swift-dev >
> Subject: [swift-evolution] End of source-breaking changes for Swift 3
> 
> Dear friends,
> 
> Today is July 27 — and the last planned day to take source-breaking changes 
> for Swift 3. It has been an incredible ride to this point, so let's take 
> stock of where we are. 
> 
 
> Thank you again to everyone for making Swift 3 such as fantastic release!
> 
> Ted
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 vs Swift 4

[Ted F.A. van Gaalen via swift-evolution]

Hi Chris  (and Core Team)


never,never do 
  
   
for Int i = 0; i < what? ;i++
   {

bottles = glass++ * 12 
   }

Seriously, thanks wishing you 
  time tp relax 
  and some tranquility
between the hard work!


Seriously too: (but for later)  

Can you help me -after 3.0 is there- with the making
of a proposal to bring the classical for loop back  (additive chance then) ?


thanks!

Ted


www.tedvg.com
www.ravelnotes.com  <- promote these apps, there cool!
tedvg.deviantart.com
https://soundcloud.com/ted-van-gaalen/noise-am-rhein




Note: I’ve lost some good people in life due to alcohol,
a hard drug. just be careful.



















 







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

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Ted F.A. van Gaalen via swift-evolution]

> 
> There are many empty strings in that string. In fact, there are infinite 
> empty strings between each character, before the string, and after the 
> string. Observe:
> 
> "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
> "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
> "" + "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42"
> "" + "" + "" + "" + "Don’t Panic: Please read Hitchhiker’s Guide to the 
> Galaxy 42"
> etc, and I didn't even get past the first character!
> 

Wel, maybe I am not intelligent enough to comprehend that,
or maybe it’s just a matter of definition/convention..
 
Again, to me a string is ***just a row of characters***. 

therefore, concatenating empty strings (that do not contain any characters)  
with other strings have no effect: . 
for example: 

   let res = "" + "" + "" + "" + “The Art Of Learning To Fly”

after that: 
  
 res == “The Art Of Learning To Fly”

and:

 res.count == “The Art Of Learning To Fly”.count

Regardless what in many  other programming languages  is done;
I prefer the Objective jC NSString hasPrefix(“") way of handling this,
which always returns False,e because a row of characters
is contiguous, without empty “” in between, leading or trailing.  

However, we don’t seem to share the same opinion, about this sorry. 
nothing more to say about that, I guess.

TedvG



>> On Jul 20, 2016, at 6:49 PM, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Don’t Panic !
>> 
>> At the risk of seeing things in a somewhat trivial perspective,
>> combined with an almost complete absence of abstraction:
>> 
>> Note that to relatively simple persons like me: 
>> 
>> String instances are just rows of characters (when not empty, of course) 
>> 
>> There are only two kinds of Strings:
>> 
>> 1. empty Strings, which do not contain amy characters at all
>> 
>>   and 
>> 
>> 2.  Strings containing 1 or more characters.
>> 
>> Ergo ad Infinitum :
>> 
>> Empty Strings do not occur in Strings that contain characters. 
>> 
>> 
>> I’d say, please try to find possible empty strings
>> that might perhaps be embedded e.g. in the string below: 
>>  
>> “Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42” 
>> 
>> 
>> With all due respect: 
>> This might void the discussion below :o)
>> 
>> I have nothing against Mathematics as long
>> as it is applicable.
>> 
>> 
>> Kind Regards
>> Ted
>> 
>> 
>> 
>>> To the question of whether any given string has the empty string as prefix:
>>> yes it does. This is a correct answer, and returning true is a correct
>>> behaviour.
>>> 
>>> To the question of how many times the empty string occurs in a string: yes,
>>> this can be infinite. "a" == "a" + "" == "a" + "" + "" == "a" + "" + "" +
>>> "" == "a" + "" + "" + "" + "" == ... etc.. Concatenating an empty string,
>>> like adding zero or multiplying by zero for a numerical value, can be done
>>> infinitely many times without making a difference.
>>> 
>>> However, there's correctness and convenience. For example, every integer
>>> can be expressed as a multiple of prime factors. 1 is technically a prime
>>> number - it's divisible by 1 and itself - but for convenience we say it
>>> isn't a prime number, because if it isn't, every integer can be expressed
>>> uniquely as a multiple of prime factors, whereas if it is, there are an
>>> infinite number of such expressions for each integer.
>>> 
>>> There may be many algorithms which rely on an empty prefix returning false.
>>> If hasPrefix and hasSuffix are corrected, those algorithms should be
>>> altered to recognise that correction. For example, if breaking up a string
>>> using the empty string as a separator, it seems sensible that the sequence
>>> of substrings would never contain consecutive empty strings.
>>> 
>>> On Wed, Jul 20, 2016 at 11:58 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>>> I'd run this by someone who actually knows

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Ted F.A. van Gaalen via swift-evolution]

> On 21.07.2016, at 03:15, Saagar Jha <saagarjh...@gmail.com> wrote:
> 
> 
> Saagar Jha
> 
> 
> 
>> On Jul 20, 2016, at 18:02, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi Nevin,
>> 
>> extension String
>> {
>> var count: Int
>> {
>> get
>> {
>> return self.characters.count
>> }
>> }
>> 
>> // Sigh... String subscriptors should be already builtin in the String
>> 
> 
> Swift Strings use grapheme clusters, so subscripting doesn’t really work.
?? sorry Saagar, but it does! try this code in Swift Playground
I mean that the subscritp functions implemented below could just as well be 
builtin.
Ted
> 
>> subscript (idx: Int) -> String
>> {
>> get
>> {
>> return self.substringWithRange(
>> 
>> self.startIndex.advancedBy(idx)..<self.startIndex.advancedBy(idx + 1)
>> )
>> }
>> }
>> 
>> // range subscript [n1..n2] or [n1...n2]
>> 
>> 
>> subscript (r: Range) -> String
>> {
>> get
>> {
>> return self.substringWithRange(
>> 
>> self.startIndex.advancedBy(r.startIndex)..<self.startIndex.advancedBy(r.endIndex)
>>   )
>> }
>>  }
>> 
>> //
>> func hazPrefix(s: String) -> Bool
>> {
>> if self.isEmpty && s.isEmpty  // both are empty: match
>> {
>> return true
>> }
>> 
>> if self.isEmpty || s.isEmpty ||
>>(s.count > self.count)
>> {
>> return false
>> }
>> 
>> var match = true
>> 
>> for i in 0..> {
>> if self[i] != s[i]
>> {
>> match = false
>> break
>> }
>> }
>> 
>> return match
>> }
>> ///
>> } // end String extensions.
>> 
>> 
>> 
>> let s = "abcdefghijklmnopqrstuvwxyz"
>> let emptystr = ""
>> let emptystr2 = ""
>> 
>> print( s.hazPrefix("abc") )   // true
>> 
>> print( s.hazPrefix("") )  // false
>> print( s.hazPrefix("Led Zeppelin.") ) // false
>> print( emptystr.hazPrefix("Swift") )  // false
>> 
>> print(emptystr.hazPrefix(emptystr) )  // true
>> 
>> 
>> Please see further in-line comments below: 
>> 
>> Kind Regards,
>> Ted
>>  
>> 
>>> On 21.07.2016, at 00:57, Nevin Brackett-Rozinsky 
>>> <nevin.brackettrozin...@gmail.com 
>>> <mailto:nevin.brackettrozin...@gmail.com>> wrote:
>>> 
>>> On Wed, Jul 20, 2016 at 6:32 PM, Ted F.A. van Gaalen via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> Hi,
>>> 
>>> Mathematical correct or not: 
>>> 
>>> in case of 
>>>  s1.hasPrefix(s2)
>>>  (or any other containment test method) 
>>> 
>>> s1 and s2 are just plain simple instances of String,
>>> nothing more nothing less. 
>>> 
>>> Which is interpreted by me as: 
>>> “test if String s1 starts with String s2”
>>> 
>>> 
>>> …which means, “Do the first n characters of s1 match s2, where n is the 
>>> length of s2?”
>> Yes,. and of course  s1.count   <= s2.count. 
>>> 
>>> When s2 is the empty string, n is 0.
>> 
>>> 
>>> What are the first 0 characters of s1? Clearly the empty string, since that 
>>> is the only string with 0 characters.
>>> 
>>> Do the first 0 characters of s1 match s2? Well they are both the empty 
>>> string, and ""=="" is true, so…
>>> 
>>> That would be a resounding “Yes!”
>> how  dumb (for “”.hasPrefix(“”) ), my mistake. (handled correctly imho in 
>> code example above)
>> however, that is a matter of definition:
>> should “search for nothing in nothing” return “true” ??
> 
> Yes. For example, if y

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Ted F.A. van Gaalen via swift-evolution]

Don’t Panic !

At the risk of seeing things in a somewhat trivial perspective,
combined with an almost complete absence of abstraction:

Note that to relatively simple persons like me: 

String instances are just rows of characters (when not empty, of course) 

There are only two kinds of Strings:

1. empty Strings, which do not contain amy characters at all

  and 

2.  Strings containing 1 or more characters.

Ergo ad Infinitum :

Empty Strings do not occur in Strings that contain characters. 


I’d say, please try to find possible empty strings
that might perhaps be embedded e.g. in the string below: 
 
“Don’t Panic: Please read Hitchhiker’s Guide to the Galaxy 42” 


With all due respect: 
This might void the discussion below :o)

I have nothing against Mathematics as long
as it is applicable.


Kind Regards
Ted



> To the question of whether any given string has the empty string as prefix:
> yes it does. This is a correct answer, and returning true is a correct
> behaviour.
> 
> To the question of how many times the empty string occurs in a string: yes,
> this can be infinite. "a" == "a" + "" == "a" + "" + "" == "a" + "" + "" +
> "" == "a" + "" + "" + "" + "" == ... etc.. Concatenating an empty string,
> like adding zero or multiplying by zero for a numerical value, can be done
> infinitely many times without making a difference.
> 
> However, there's correctness and convenience. For example, every integer
> can be expressed as a multiple of prime factors. 1 is technically a prime
> number - it's divisible by 1 and itself - but for convenience we say it
> isn't a prime number, because if it isn't, every integer can be expressed
> uniquely as a multiple of prime factors, whereas if it is, there are an
> infinite number of such expressions for each integer.
> 
> There may be many algorithms which rely on an empty prefix returning false.
> If hasPrefix and hasSuffix are corrected, those algorithms should be
> altered to recognise that correction. For example, if breaking up a string
> using the empty string as a separator, it seems sensible that the sequence
> of substrings would never contain consecutive empty strings.
> 
> On Wed, Jul 20, 2016 at 11:58 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org > wrote:
> 
>> I'd run this by someone who actually knows math, but afaik there are
>> finitely many empty strings in any given string.
>> 
>> How many e's are in any given string? (Ignoring Unicode issues for now,)
>> for each index in the string's indices, form a substring one character in
>> length starting at that index and compare the value of that substring to e.
>> 
>> How many empty strings are in any given string? For each index in the
>> string's indices, form a substring zero characters in length starting at
>> that index and compare the value of that substring to an empty string.
>> 
>> 
>> 
>> On Wed, Jul 20, 2016 at 17:35 Guillaume Lessard <
>> gless...@tffenterprises.com > wrote:
>> 
>>> 
 On 20 juil. 2016, at 14:21, Xiaodi Wu > wrote:
 
 Doesn't your second argument undermine your first? If it's a trivial
>>> solution and one rarely ever considers empty strings when invoking
>>> `hasPrefix`, then returning the technically correct result must be a
>>> trivial departure in behavior.
>>> 
>>> I specifically used an example where the trivial solution (y=0 instead of
>>> y=exp(x)) is a pitfall.
>>> 
>>> How many empty strings are contained in any given string?
>>> If the answer is infinitely many, it sounds like a pitfall to me.
>>> 
>>> Cheers,
>>> Guillaume Lessard
>>> 
>>> 
>> ___
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Ted F.A. van Gaalen via swift-evolution]

Hi Nevin,

extension String
{
var count: Int
{
get
{
return self.characters.count
}
}

// Sigh... String subscriptors should be already builtin in the String

subscript (idx: Int) -> String
{
get
{
return self.substringWithRange(

self.startIndex.advancedBy(idx)..<self.startIndex.advancedBy(idx + 1)
)
}
}

// range subscript [n1..n2] or [n1...n2]


subscript (r: Range) -> String
{
get
{
return self.substringWithRange(

self.startIndex.advancedBy(r.startIndex)..<self.startIndex.advancedBy(r.endIndex)
  )
}
 }

//
func hazPrefix(s: String) -> Bool
{
if self.isEmpty && s.isEmpty  // both are empty: match
{
return true
}

if self.isEmpty || s.isEmpty ||
   (s.count > self.count)
{
return false
}

var match = true

for i in 0.. On 21.07.2016, at 00:57, Nevin Brackett-Rozinsky 
> <nevin.brackettrozin...@gmail.com> wrote:
> 
> On Wed, Jul 20, 2016 at 6:32 PM, Ted F.A. van Gaalen via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Hi,
> 
> Mathematical correct or not: 
> 
> in case of 
>  s1.hasPrefix(s2)
>  (or any other containment test method) 
> 
> s1 and s2 are just plain simple instances of String,
> nothing more nothing less. 
> 
> Which is interpreted by me as: 
> “test if String s1 starts with String s2”
> 
> 
> …which means, “Do the first n characters of s1 match s2, where n is the 
> length of s2?”
Yes,. and of course  s1.count   <= s2.count. 
> 
> When s2 is the empty string, n is 0.

> 
> What are the first 0 characters of s1? Clearly the empty string, since that 
> is the only string with 0 characters.
> 
> Do the first 0 characters of s1 match s2? Well they are both the empty 
> string, and ""=="" is true, so…
> 
> That would be a resounding “Yes!”
how  dumb (for “”.hasPrefix(“”) ), my mistake. (handled correctly imho in code 
example above)
however, that is a matter of definition:
should “search for nothing in nothing” return “true” ??

Again, Strings to me are just character arrays...
 
> 
> Nevin
> 
> 
>  
> which, to me,  implies that one will never find an occurrence
> of an empty string within another string,
> for the very simple reason that an empty string
> does not exist within another string. **
> Ergo: “false” is the right evaluation when s2.isEmpty.
> 
> ** In my mental model, a String is just an array of 0...n characters,
>   like it is in most languages, very straightforward.
> 
>  (returning false) This is exactly the reason why NSString does that, 
> for more than 20 years, why change it?
> 
> AFAIK no one has complained about this for years, 
> because imho it is logically sound. 
> 
> for a compiler this is very easy
> all it has to do is to return False
> when either s1 or s2 is empty.
> 
> 
> Ted
> 
> 
>> On 19.07.2016, at 23:11, Jacob Bandes-Storch <jtban...@gmail.com 
>> <mailto:jtban...@gmail.com>> wrote:
>> 
>> Not that it's needed, but another +1 from me.
>> 
>> a.hasPrefix(p) should be true iff there exists some string x for which p+x 
>> == a.  If p == "", then x := a satisfies this, so hasPrefix should return 
>> true.
>> 
>> Jacob
>> 
>> On Tue, Jul 19, 2016 at 1:29 PM, Jaden Geller via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> Both `hasPrefix` and `hasSuffix` are analogous to the more general 
>> `hasSubset` function, which would return `true` for the empty set.
>> 
>>> On Jul 19, 2016, at 12:32 PM, Bianca via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> > Empty set is a subset of all sets.
>>> 
>>> True but all sets certainly do not _contain_ the empty set, which is what 
>>> might be confusing, as the word "contains" in the context of sets implies 
>>> that it's a member of the set of characters that make up a String. 
>>> 
>>> On Tue, Jul 19, 2016 at 12:23 PM Charlie Monroe via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> > On Jul 19, 2016, at 6:17 PM, Ted F.A. van Gaalen via swift-evolution 
>>> > <swift-evolution

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Ted F.A. van Gaalen via swift-evolution]

Hi,

Mathematical correct or not: 

in case of 
 s1.hasPrefix(s2)
 (or any other containment test method) 

s1 and s2 are just plain simple instances of String,
nothing more nothing less. 

Which is interpreted by me as: 
“test if String s1 starts with String s2”

which, to me,  implies that one will never find an occurrence
of an empty string within another string,
for the very simple reason that an empty string
does not exist within another string. **
Ergo: “false” is the right evaluation when s2.isEmpty.

** In my mental model, a String is just an array of 0...n characters,
  like it is in most languages, very straightforward.

 (returning false) This is exactly the reason why NSString does that, 
for more than 20 years, why change it?

AFAIK no one has complained about this for years, 
because imho it is logically sound. 

for a compiler this is very easy
all it has to do is to return False
when either s1 or s2 is empty.


Ted


> On 19.07.2016, at 23:11, Jacob Bandes-Storch <jtban...@gmail.com> wrote:
> 
> Not that it's needed, but another +1 from me.
> 
> a.hasPrefix(p) should be true iff there exists some string x for which p+x == 
> a.  If p == "", then x := a satisfies this, so hasPrefix should return true.
> 
> Jacob
> 
> On Tue, Jul 19, 2016 at 1:29 PM, Jaden Geller via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> Both `hasPrefix` and `hasSuffix` are analogous to the more general 
> `hasSubset` function, which would return `true` for the empty set.
> 
>> On Jul 19, 2016, at 12:32 PM, Bianca via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> > Empty set is a subset of all sets.
>> 
>> True but all sets certainly do not _contain_ the empty set, which is what 
>> might be confusing, as the word "contains" in the context of sets implies 
>> that it's a member of the set of characters that make up a String. 
>> 
>> On Tue, Jul 19, 2016 at 12:23 PM Charlie Monroe via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> > On Jul 19, 2016, at 6:17 PM, Ted F.A. van Gaalen via swift-evolution 
>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> >
>> > 1.  return “false”  seems to me logically correct, because
>> > there is never an empty string in another string, and an empty string 
>> > cannot contain another empty string, right?
>> 
>> Empty set is a subset of all sets.
>> 
>> Just like:
>> 
>> let arr1: [String] = ["Hello", "Swift", "Evolution"]
>> let arr2: [String] = []
>> arr1.starts(with: arr2, isEquivalent: ==) // true
>> 
>> >This has worked very conveniently for NSString in ObjC for more than 20 
>> > years, why change it?
>> >Do you know of cases that were problematic with this convention?
>> >
>> >
>> > 2  throw a runtime error when trying to do this:
>> >str.hasPrefix(“”) //  also for hasSuffix,  str.contains etc.
>> >
>> > some in-line questions below.
>> >
>> > Kind Regards
>> >
>> > Ted
>> >
>> >
>> > On 19.07.2016, at 16:31, Dave Abrahams <dabrah...@apple.com 
>> > <mailto:dabrah...@apple.com>> wrote:
>> >>
>> >>
>> >> on Tue Jul 19 2016, "Ted F.A. van Gaalen" > >> <http://tedvgiosdev-at-gmail.com/>> wrote:
>> >>
>> >>> Hi Dave
>> >>>
>> >>> “true” ? am I going nuts ? :o)
>> >>>
>> >>> var str = "Hello, playground"
>> >>>
>> >>> print( str.hasPrefix("”)) // case 1 : false
>> >>>
>> >>> print( str.hasSuffix("”)) // case 2 : false
>> >>>
>> >>> print("" == “a” )  // case 3 : false
>> >>>
>> >>> Currently, all cases above evaluate to “false”
>> >>> i think that is correct,
>> >>
>> >> I don't know what to tell you.  It may seem intuitively correct to you,
>> >> but others in the thread have laid out the reasons why it is not
>> >> mathematically correct behavior.
>> > Where? I couldn’t find any.
>> >> One other way of rephrasing it: to get
>> >> `false` for str.hasPrefix(""), you actually need special-case code in
>> >> hasPrefix to check for the empty string,
>> > again, maybe it 

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Ted F.A. van Gaalen via swift-evolution]

ok, Dave



to me - strings being collections -, all I see is:
trying to find an empty string within another string: There are (at least) two 
ways of treating this:

1.  return “false”  seems to me logically correct, because
 there is never an empty string in another string, and an empty string 
cannot contain another empty string, right? 
This has worked very conveniently for NSString in ObjC for more than 20 
years, why change it? 
Do you know of cases that were problematic with this convention? 
   

2  throw a runtime error when trying to do this:
str.hasPrefix(“”) //  also for hasSuffix,  str.contains etc.

some in-line questions below.

Kind Regards

Ted


On 19.07.2016, at 16:31, Dave Abrahams  wrote:
> 
> 
> on Tue Jul 19 2016, "Ted F.A. van Gaalen"  wrote:
> 
>> Hi Dave
>> 
>> “true” ? am I going nuts ? :o) 
>> 
>> var str = "Hello, playground"
>> 
>> print( str.hasPrefix("”)) // case 1 : false
>> 
>> print( str.hasSuffix("”)) // case 2 : false
>> 
>> print("" == “a” )  // case 3 : false
>> 
>> Currently, all cases above evaluate to “false”
>> i think that is correct, 
> 
> I don't know what to tell you.  It may seem intuitively correct to you,
> but others in the thread have laid out the reasons why it is not
> mathematically correct behavior.  
Where? I couldn’t find any. 
> One other way of rephrasing it: to get
> `false` for str.hasPrefix(""), you actually need special-case code in
> hasPrefix to check for the empty string,
again, maybe it should throw a run-time error instead.


> and the caller may well also
> need special-case code to handle the fact that the result is not
> mathematically consistent with other cases on the continuum.
In this context as “continuum” : 
   are you referring to  “sets” or “collections” here?
what other cases? 

>  Doing
> things that way doesn't work in practice for real programs.
please explain thank you, because I see no problems at
all with the current NSString-like evaluation…
I’d put an s.isEmpty() in front of it.
> 
>> because:
>> 
>> How can an empty string be a prefix or suffix value?
>> as there is no empty string present in a non-empty string. 
>> 
>> Note that if case 1 and case 2 would evaluate to “true”, 
>> it would conflict with case 3. 
>> 
>> Can’t imagine that case 3 should in future also result in “true” 
>> 
>> ??
>> 
>> -
>> 
>> Also I hope that changes to String functionality
>> for Swift 4 are not backward breaking changes
>> even the more for string handling, because Strings 
>> are heavily used in most apps. 
>> 
>> I am firmly convinced that all future releases of Swift 
>> should compile Swift 3 and higher source files without
>> any changes 100 % flawlessly! This prevents early diminishing 
>> of Swift’s popularity, especially with those building large
>> codebases using Swift. 
>> 
>> I’ve started a thread about this a week ago,
>> however no one found this important enough to
>> share their opinions with me yet, or were too busy with
>> other subjects to do so.
>> 
>> Increasingly I have dreams, me
>> programming complete apps in Smalltalk
>> and then automagically generate 
>> an macOS, tvOS or iOS runtime app of it.
>> 
>> (I have also dreams of this world becoming
>> a nice and peaceful placebut that is 
>> beyond the context of this forum)
>> 
>> Kind Regards
>> TedvG 
>> 
>> www.speyer.de
>> 
>>> on Mon Jul 18 2016, Kevin Nattinger >> > wrote:
>>> 
 I agree, true is definitely the expected behavior. In particular, it
 seems absurd to me that `a.hasPrefix(b)` and `a.hasSuffix(b)` could be
 false when `a == b` is true.
>>> 
>>> I expect to be reworking Strings for Swift 4, and this is one of the
>>> many things we plan to address.
>>> 
>>> -- 
>>> Dave
>>> 
>>> 
>> 
> 
> -- 
> Dave

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

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

[Ted F.A. van Gaalen via swift-evolution]

Hi Dave

“true” ? am I going nuts ? :o) 

var str = "Hello, playground"

print( str.hasPrefix("”)) // case 1 : false

print( str.hasSuffix("”)) // case 2 : false

print("" == “a” )  // case 3 : false


Currently, all cases above evaluate to “false”
i think that is correct, because:

How can an empty string be a prefix or suffix value?
as there is no empty string present in a non-empty string. 

Note that if case 1 and case 2 would evaluate to “true”, 
it would conflict with case 3. 

Can’t imagine that case 3 should in future also result in “true” 

??


-

Also I hope that changes to String functionality
for Swift 4 are not backward breaking changes
even the more for string handling, because Strings 
are heavily used in most apps. 

I am firmly convinced that all future releases of Swift 
should compile Swift 3 and higher source files without
any changes 100 % flawlessly! This prevents early diminishing 
of Swift’s popularity, especially with those building large
codebases using Swift. 

I’ve started a thread about this a week ago,
however no one found this important enough to
share their opinions with me yet, or were too busy with
other subjects to do so.

Increasingly I have dreams, me
programming complete apps in Smalltalk
and then automagically generate 
an macOS, tvOS or iOS runtime app of it.

(I have also dreams of this world becoming
a nice and peaceful placebut that is 
beyond the context of this forum)


Kind Regards
TedvG 



www.speyer.de




 

> on Mon Jul 18 2016, Kevin Nattinger  > wrote:
> 
>> I agree, true is definitely the expected behavior. In particular, it
>> seems absurd to me that `a.hasPrefix(b)` and `a.hasSuffix(b)` could be
>> false when `a == b` is true.
> 
> I expect to be reworking Strings for Swift 4, and this is one of the
> many things we plan to address.
> 
> -- 
> Dave
> 
> 

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

[swift-evolution] Avoiding back breaking changes and removals.

[Ted F.A. van Gaalen via swift-evolution]

Hi Jean-Denis

please look at my response in-line further down.

I am also writing this text because I think
that the implications of back breaking chances
are severely underestimated.

Again, the scope of my writing concerns the situation after Swift 3.0

Veuillez recevoir, Monsieur, nos salutations distinguées.

Ted


> On 07.07.2016, at 14:12, Jean-Denis Muys  wrote:
> 
> Ted,
> 
> I basically disagree 100% with everything you wrote.
Ok, it was a bit supercharged as in effect, I meant
only source breaking changes.

However also my recommendation to move a bit slower 
for a year or two so that people (not only the Swift-evolution participants)
really have started using Swift is a consideration… to get
more matured feedback, which then can play an important
role in improving Swift further. 

> I will not got into much details, but for me, technology that doesn’t evolve 
> is dead technology.

I agree with this of course! 

 The subject title I gave this thread: 
> "Seriously! Freeze Swift For Two YearsAfter Release 3.0 !”

and also what I wrote was a bit over-dramatic. That is a bit my nature…:o) 
sorry. 
Now  it has a more appropriate subject title as you can see above.

What I (but who am I?) would prefer is:

All improvements and changes should be supplemental only.
thus leaving what is already there intact.
  
 ===
 This Would 100%  Guarantee That  Everything Ever Built, Never Needs To Be 
Changed.
 ===

(that is, within the scope and context of the programming language itself, of 
course) 

This is certainly feasible and proven: there are a number of programming 
languages that
adhere to this basic rule. This is e.g. the case with the classical languages 
Cobol and PL/1 for
C, C++ for  example.
 
> 
> Moreover, your main argument about large code bases, is not a good one: we 
> now have migration tools that work quite well. They could be made even 
> better, with some investment, that most (I think) would rather see invested 
> in the leading edge.

As I wrote before, I think that in many cases converters/ migration tools 
are certainly helpful,however they work mostly scanning on a 
statement-by-statement basis, 
having "not enough AI” to grasp and process the context 
e.g. for a cluster of source lines…

Imho, it is nearly impossible to write a migration tool that catches everything
and automatically converts flawlessly.
Making such a migrator would probably use as much or even more effort
as making the Swift compiler itself.

I have worked for many years in IT-environments with extremely large
and often ancient code bases (Mainframe, banks insurance companies etc.)

In these environments,- even without source migration - 
it is extremely difficult to apply changes to existing software, thousands of
sources scattered al over the place: a myriad of chaotic intertwined sub 
systems, 
often badly connected via middle ware, chaotic file systems etc.  Yes, from 
time to time
change managers/firms are hired, however,  in many cases this makes it even 
worse.
Note that this is not a worst case scenario but the average large systems 
scenario.


> Aversion to change is everywhere. It’s deeply engrained in us human beings.

Yes, very true, albeit that it is a very understandable feature of human 
intuition
as changes are risky in many cases. This does not imply that change
should be avoided at all times of course! Apparently I gave this impression 
unintentionally in my previous writing. 

Especially in IT , the reluctancy to change is very plausible if changes bring 
severe risk of malfunctioning systems. For example changes to large bank’s 
accounting systems literally consisting of thousands of programs, modules
and files and a few different databases simultaneously.. These systems are
extremely fragile.

When changes applied go wrong, it cause severe financial damage. 
It happens many times as it is very hard to foresee the impact 
and side-efects these changes might have in 
large (and mostly hybrid) systems.

So imagine something so trivial as changing the Cobol assignment statement
"MOVE A TO B.”  to  "COPY A INTO B."
(which btw would have been more correct, because basically that is what it does)
 
Even such a small change  can have an enormous impact. On top of that,
as changes to sources also need a conversion cycle when there is backwards 
breaking the situation will be extremely difficult. 
The example here is just a trivial case.  

A hypothetic but realistic example:

Swift is intended as a general purpose language, so, what prevents
us from writing a complete accounting system with Swift? 

Let’s assume a company decides to (re)built its complete company-wide 
accounting system using Swift as its main programming language. 
About 40 Swift programmers are hired, they manage
to built this accounting system in even less that a year. 

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

[Ted F.A. van Gaalen via swift-evolution]

Hi Chris,

Yes, I did read it again, subscribe to that strategy.

I’ve perhaps over-emphasized the importance of the impact back-breaking changes
.. Still..   

The subject title was a bit overloaded too.

I guess it’s between two extremes: that is, between (1) really freezing it and
(2) using Swift as a continuous "software laboratory”   :o)
neither would be OK, (as with all extremities)...

thanks
Ted  


> On 10.07.2016, at 00:20, Chris Lattner  wrote:
> 
> 
>> On Jul 9, 2016, at 12:41 PM, Ted F.A. van Gaalen  
>> wrote:
>> 
>> imho and after releasing Swift 3.0: 
>>  ===
>> 
>> Existing language elements should never be removed,
>>   (even if they are frowned upon, which occasionally is caused
>>by aspects of subjective opinion, lack of experience and premature vague 
>> statistics, we’re human aren’t we?)
>> and even if much better newer solutions are available. 
>> 
>> New language elements should be supplements, standing on their own,
>> with the purpose of extending Swift, not as changes of existing code, 
>> thus leaving the older equivalents intact as not to break older source code. 
> 
> Ted,
> 
> I recommend that you familiarize yourself with the goals for Swift 3, which 
> are described here:
> https://github.com/apple/swift-evolution
> 
> An excerpt:
> 
> "The primary goal of this release is to solidify and mature the Swift 
> language and development experience. While source breaking changes to the 
> language have been the norm for Swift 1 through 3, we would like the Swift 
> 3.x (and Swift 4+) languages to be as source compatible with Swift 3.0 as 
> reasonably possible.”
> 
> -Chris

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

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

[Ted F.A. van Gaalen via swift-evolution]

> On 08.07.2016, at 00:33, Chris Lattner  wrote:
> 
> On Jul 7, 2016, at 7:46 AM, Karl  wrote:
>> Not only that, but we have compiler fix-its. When there are renaming changes 
>> or argument-label changes, I just filter down my Xcode error list, click 
>> each one, give it a quick eyeball and hit “enter”. I don’t know of other 
>> languages that have had such good migration infrastructure for existing 
>> code. I don’t know how Linux users get the benefit of these fixits, though. 
> 
> Helpful hint for folks moving from Xcode 8.0 beta 1 to beta 2 (and beyond): 
> when you open your project in a new beta, make sure to go to "Edit -> Convert 
> -> To Modern Swift Syntax…”, which will help move you up by automatically 
> applying the migration fixits that correspond to the changes in the new beta.
> 
> -Chris
> 
Hi Chris, sorry for the delayed response.

In many cases Swift converters/ migration tools are certainly helpful,
however they work mostly scanning on a statement-by-statement basis, 
having "not enough AI” to grasp and process the context 
e.g. for a cluster of source lines...

So, e.g. if one has programmed a function with its logic heavily based
on deprecating or removed Swift language elements, one still has to edit and
retest that code, which mostly consumes lots of time. Additionally, 
in many cases - albeit somewhat reduced by good structured design -
these changes influences also other parts of the application. 
(but we all know that of course)


imho and after releasing Swift 3.0: 
   ===

Existing language elements should never be removed,
(even if they are frowned upon, which occasionally is caused
 by aspects of subjective opinion, lack of experience and premature vague 
statistics, we’re human aren’t we?)
and even if much better newer solutions are available. 

New language elements should be supplements, standing on their own,
with the purpose of extending Swift, not as changes of existing code, 
thus leaving the older equivalents intact as not to break older source code. 

 (it would then to be expected that,
  if better alternatives are made available
 these would of course be preferred,
 causing the older alternatives to be forgotten 
 after some time. Like the classical for-loop for instance.
 but, they’re still there to stay compatible with older source code) 

-Even renaming language elements makes revisiting
and editing often large amounts of source code necessary.

Yes, I know this can be quite a challenge, nevertheless
it is necessary, i think. 

In a (often unforgiving and stressed) production-environment
we used to write code in a “fire and forget” modus,
that is once written and tested it should run forever! 

There simply is no time for revisiting. For instance, if one
would have to re-edit an old source to make minor
changes, then it wouldn’t be enough to just correct
this perhaps minor error, as one would have to edit
many source lines because the compiler won’t accept
language elements used some time ago and
now rendered obsolete.

Unless you allow to compile conditionally for each and every version
of the language. But conditional compiling creates a
mess, and makes source code hard to maintain.

Changing language elements or, even worse, removing them
makes it a tedious and very costly necessity to revisit and 
re-edit all previously written source code, not to mention
that after that, all application/libraries involved need to be 
tested again! 

If it is just a trivial application, then this still could be done
without too much effort, however, in more complex cases
this could result in a real nightmare, consuming lots of time and money.

If i am not mistaken, the word “deprecated” originated in the Java
world. There the questionable culture of rücksichtslos throwing
things away started, I guess. Trendy perhaps? 
In this culture, tons of Java code needs to be revised, 
tested and re-released almost yearly because of that.

I think we should not make the same mistake.

Changing things all the time would certainly diminish Swift’s 
popularity by professional developers.

In all these years as a programmer my general experience is,
that  improvements in programming languages are supplemental*
not changes or removal from existing language elements. 

As perhaps misunderstood (from my previous writing) by some of us:
Of course I am not in favor of stopping development of Swift. 
but imho as described above, changes should be supplemental
and not replacing existing language elements or removing them. 

In this perspective “Freezing Swift” is meant here to keep all 
new supplements in beta, yes, for a prolonged time, 2 years or so. 
In that time Swift will have many more users, that no doubt, will 
come with valuable feedback allowing to 
improve the language even better.  

Please note that all the writing and considerations above concerns the
time 

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Ted F.A. van Gaalen via swift-evolution]

>   * What is your evaluation of the proposal?


With all due respect, what is proposed here is imho completely unnecessary
and needlessly complicates Swift further. 

- in Object oriented development, subclassing should be encouraged, not limited.
 if one desires a class not to be subclassed simply add the modifier “final”

Using “final” (as in Java or C++) or “sealed” (as in C#) is imho the best way 
to do it.


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

No !  

>   * Does this proposal fit well with the feel and direction of Swift?

This is a subjective domain. can’t answer that.  Anyway, it’s against the basic 
principles of OOD/OOP

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

N/A

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I’ve read the proposal...


My opinion is based upon years of experience with OOP languages like Smalltalk, 
Java, Delphi Pascal, Objective C and C++ 

Kind Regards, now from speyer.de. 

Ted


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

Re: [swift-evolution] multi-line string literals.

[Ted F.A. van Gaalen via swift-evolution]

Hi Brent,

@Dave - Hi Dave, please see at the end of this email. 

Thanks for your energetic reply, Brent.
First of all, I think there is a place in Swift for “your” and “mine” proposing 
solutions 
together. I will reply further inline -> 
> On 30.04.2016, at 09:43, Brent Royal-Gordon  wrote:
> 
>> Example 1. The \@ operator: 
>> 
>>   // 1.  multi-line string literal with data lines as is. 
>> // It loads each line (part) up to and including the 
>> source-file-line- end:
>> // you can use all available characters without problems, 
>> // even \\ and \@  thus allowing you to nest e.g. Swift 
>> statements...  
>> 
>> let xml =
>> \@
>>   \@  
>>   \@  // this is not 
>> regarded as a comment.
>>   \@   //¯\"_(ツ)_//
>>   \@
>> \@   
>> 
>> 
>>   Example 2, The \\ operator: 
>>   // Multi-line string literal with data lines with \n \t etc. respected: 
>> 
>> var str =
>> \\This is line one.\nThis is line two, with a few \t\t\t 
>> tabs in it...
>> \\
>> \\This is line three: there are \(cars) 
>> // this is a comment.
>> \\ waiting in the garage. This is still line three
> 
> There are a lot of reasons why I don't like these.
> 
> The first is simply that I think they're ugly
To me, that is not relevant: 
If something is “ugly”  or not is tied to different and unique 
personal reference, accumulated by experience and 
human instinct and are thus not comparable because no two 
beings are the same. Ergo: This voids a discussion between 
you and me about this subjective aspect “ugliness” 
Still, this aspect should be subordinate to functionality
 (in this case the functionality of a programming language).


> and don't look like they have anything to do with string literals,
You’re right about that:  they are not *string literals* but *data lines*.

 
> but that's solvable. For instance, we could modify my proposal so that, if 
> you were using continuation quotes, you wouldn't have to specify an end quote:
> 
> let xml =
> "
>"  
>"  // this is not 
> regarded as a comment.
>"   //¯\"_(ツ)_//
>"
> "   

Essentially the above is similar to what I propose with “my” data line,
that is, starting each line with a special character/token. But that is where 
the
similarity ends: It does not offer processing for *both*:
- "as-is" character data
-  character data where escaped characters need to be processed.
   
> 
> So let's set the bikeshed color aside and think about the deeper problem, 
> which is that line-oriented constructs like these are a poor fit for string 
> literals.

> 
> A string literal in Swift is an expression, and the defining feature of 
> expressions is that they can be nested within other expressions.
That is logically correct, (but desirable in all cases? (readability)) however: 
   
As said before, these \@…..  and \\…..   are data lines, not string literals. 
They are not intended to replace string literals.  A slightly different concept.

Data lines are just that and -apart from assignment, that is to be loaded in a 
String variable or constant- 
not really intended to take further part in expressions. 
however you can still do that, as shown further below.  


> We've been using examples where we simply assign them to variables, but quite 
> often you don't really want to do that—you want to pass it to a function, or 
> use an operator, or do something else with it. With an ending delimiter, 
> that's doable:
> 
>   let xmlData = 
> "
>"  
>"  // this is not 
> regarded as a comment.
>"   //¯\"_(ツ)_//
>"
> "  ".encoded(as: UTF8)
I do experience this as being “ugly”, but again, this is personal.
> 
> But what if there isn't a delimiter? You would't be able to write the rest of 
> the expression on the same line. In a semicolon-based language, that would 
> merely lead to ugly code:
> 
>   let xmlData = 
> "
>"  
>"  // this is not 
> regarded as a comment.
>"   //¯\"_(ツ)_//
>"
> "  
>.encoded(as: UTF8);
> 



In “my” case this would be:

   let xml =
 \@
 \@  
 \@  // this is not 
regarded as a comment.
   

Re: [swift-evolution] multi-line string literals.

[Ted F.A. van Gaalen via swift-evolution]

>>  let xml = _"
>>  "
>>  " 
>>  " \(author)
>>  " 
>>  "”_

If I am reading and understanding this correctly:
This solution is still delimiter-sensitive and
breaks if“_ delimiter is found somewhere within the data,
because it is interpreted as end-of-string.

I wrote already about my solution   
which solves the above deficiency, 
because it does not use delimiters at all.

I have thought it all over and cleaned it up. Here it is again,
hopefully this description is more clear and readable.

Data Line Operators. 

For convenience, I call these \\ and \@ :  “data-line-operators” .
(of course, they are pseudo operators) 
Other two? character combinations for these operators are also possible. 


The  \@  data-line-operator:   
 -  takes character data "as-is” without any conversion.
 -  respects (includes) source-file line terminators.
 -  all spaces in-between and up to the source line's end are included.
 -  comments // are not seen as comments but read as data. 
 -  the \@ on its own (without anything else to the right) is implicitly an 
empty line.  
   

The  \\   data-line-operator:
   -  converts escaped chars like \t \n  and \(var) substitution, as with 
“normal" string literals.
   -  ignores trailing spaces and source-file line terminators.
   -  respects  // comments on the same line and will not include these as 
data. 
   -  the  \\ on its own is interpreted as \n (line feed)  thus (optionally) 
eliminating the 
  need for  \n usage. 

Both operators allow 0…n spaces/tabs on its left side, 
thus indentation is supported.

Example 1. The \@ operator: 

 // 1.  multi-line string literal with data lines as is. 
 // It loads each line (part) up to and including the source-file-line- 
end:
 // you can use all available characters without problems, 
 // even \\ and \@  thus allowing you to nest e.g. Swift statements...  

 let xml =
 \@
 \@  
 \@  // this is not 
regarded as a comment.
 \@   //¯\"_(ツ)_//
 \@
 \@   
 

   Example 2, The \\ operator: 
   // Multi-line string literal with data lines with \n \t etc. respected: 

 var str =
 \\This is line one.\nThis is line two, with a few \t\t\t 
tabs in it...
 \\
 \\This is line three: there are \(cars) // 
this is a comment.
 \\ waiting in the garage. This is still line three

 The first \@ or \\ must be on a new line, this is an error:

 let str =  /@data data data data…...
 /@data.


A block of \@  or \\ lines must be contiguous: with no other lines in-between.
An empty line or other source line implicitly ends the 
\\ or \@ block of lines. There is no terminator. 

 \@ and \\  lines can be mixed together in the same block.
 Should this be allowed? 



Imho even easier to understand and simple.

I could make a proposal for this later in May.

@Vladimir: sorry I didn’t respond directly on your email
You’re right. Our ideas about this have some similarity? 
Your point: 
   "and I believe I can prove we need some start-of-line marker)” :
 I think so too, that’s why I suggest the \\ and \@ data-line-operators. 
as described here.  

Too busy, packing things to move to www.speyer.de
I will read swift-evolution, but will probably not
respond until after the 12th of May or so.

Although away, some feedback would be nice, thank you.

Kind Regards
TedvG





Fri, 29 Apr 2016 08:20:34 -0600 Erica Sadun wrote: 

>> On Apr 28, 2016, at 4:52 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>>> Did you ever really use multiline string literals before?
>> 
>> Yes. I used Perl in the CGI script era. Believe me, I have used every 
>> quoting syntax it supports extensively, including `'` strings, `"` strings, 
>> `q` strings, `qq` strings, and heredocs. This proposal is educated by 
>> knowledge of their foibles.
>> 
>> As outlined in the "Future directions for string literals in general" 
>> section, I believe alternate delimiters (so you can embed quotes) are a 
>> separate feature and should be handled in a separate proposal. Once both 
>> features are available, they can be combined. For instance, using the 
>> `_"foo"_` syntax I sketch there for alternate delimiters, you could say:
>> 
>>  let xml = _"
>>  "
>>  " 
>>  " \(author)
>>  " 
>>  ""_
> 
> Other than the underscores (I'm not sold on them but I could live with them), 
> this is my favorite approach:
> 
> * It supports indented 

Re: [swift-evolution] multi-line string literals.

[Ted F.A. van Gaalen via swift-evolution]

Hi.

The solutions discussed so far have the following disadvantages:
  - They need a specific delimiter token, which cannot be used in the text 
itself.
  - The data cannot be used as-is, escape \ characters are needed.
  - Imho, they are somewhat complicated. 

In my emails previously submitted I came up with a "data line” concept,
a very simple solution, which tackles these disadvantages and is
very easy to use and understand!

Did you actually read it? 
I now quote the primary description hereunder again, in case you’ve missed it,
imaginable, because there is a lot of text flying around.

Additionally, the following improvements have developed in my thinking: 

In the mean time I consider using two tokens   \\ and \@:  
\\…data…data…data…data..   accepts data and converts \n \t etc.
or data lines starting with: 
\@…data…data…data…data… .…….  accepts data as-is, without conversion and 
 respects the linefeeds of the source-file.

the // and /@ tokens do not have to start at the beginning of a line, 
are allowed further to the right as long as there are only space(s) to the
left of it.

let music =
\\when Doves Cry\nBy Prince and
\\ The Revolution\nWhat music
\\  can be\t\t\t\tIt is \”Magic\” really.
 
If you do or don’t like this solution 
-apart from cosmetic viewpoints-
please tell me why. so I can improve it,
or try to come back with something better if i can.

let epilogue =
\@Thank you so much for reading my
\@ “contribution"  Please tell me 
\@what you think, I \value your opinion!
\@“” kind Regards! “”””"
\@ Ted. 


(the previous text following \@ data lines are accepted as-is, including 
the source-file’s linefeeds or crlf and the double quotes) 

Of course, other tokens are possible as well. 

Can’t be any simpler than this, I guess.

TedvG

===As Previously Written:=

This could be a simple solution: 

Starting each line with a special token.

In the example here it is the \\  double-backslash .  
when the \\ appears in the first two columns of a source line, 
this tells the compiler that it is a data line and that more might follow.
the last line starting with \\ completes the data entry.

Here is an example of a string declaration with some XML
(no escape sequences needed for “) 
Of course it could be anything other kind of textual data as well.

let  str =  
\\
\\
\\
\\
\\W3Schools Internal Note\n
\\
\\To: \n
\\From: \n
\\Message: 
\\
\\\n

Re: [swift-evolution] multi-line string literals.

[Ted F.A. van Gaalen via swift-evolution]

Hi Michael

What happens if a delimiter in this case: “”” 
occurs embedded in the data?   like  so (two times here):

“””
dfksposdkj dslkd s hfdslk   dskdslk  lskd sk aaasd
lfsdlks dslksd sdlk sdlksd  “””  fskfsdalkfsd  “”” fdjf dkjfds  
“”"

Having a particular token at the start of a line (or after  leading space(s) ) 
to define a data line 
allows us to use *all* available characters behind it.  

Actually after further thinking, I assume that 1 token is not enough, perhaps 
there should be two tokens e.g.
 
   \\ …...   to process  escaped chars, like \… and \(item),  
 the same way as with normal Swift string literals
 
   \@.   to take all characters as is without conversion?


Examples:
1.
let someText = 
\\There are \t \t  \(nrofboxes) boxes avai
\\lable.
converts to:
"There are 12 boxes available."

2.

let someText = 
\@There are \t \t  \(nrofboxes) boxes avai
\@able.
String taken as is, nothing is converted:
"There are \t \t  \(nrofboxes) boxes available."

Of course one could choose other tokens than \\ and \@
they just looked convenient to me...

TedvG









> On 26.04.2016, at 07:53, Michael Peternell  wrote:
> 
> """Just in my opinion:
> having to start each line with a particular token kinda defeats the purpose 
> of multiline string literals.
Why? 
> "can't we just continue"
> "the literal on the next line anyways,"
> "like in C?"
> "or maybe the "+
> "at the end of the line can be"+
> "optimized away?"
> """
> 
> What is wrong with just using """ as a delimiter? Except that maybe there are 
> other languages which use this already. You can copy whole XML snippets 
> into such a thing. It's also good for usage instructions in a command line 
> tool, and I think everyone will understand what it means. Is it a design goal 
> to do something completely new? Or are you just unhappy with all existing 
> multi-line string literal syntaxes?
> 
> -Michael (who would be happy with Perl Heredoc-Syntax as well)
> 
>> Am 26.04.2016 um 01:00 schrieb ted van gaalen via swift-evolution 
>> :
>> 
>> possible improvement, one could allow
>> leading spaces before the "data line token"
>> thus enabling indentation, like so
>> {
>>   let str =
>>  \\dataahgdfhhfdxfg cvcsffggcfg
>>  \\c jggjvhfh fhffhfgxfxgdgfhgj  jvhhfhfhcgxgc
>>.
>>.
>> }
>> 
>> TedvG
>> 
>> On 25 Apr 2016, at 20:47, Ted F.A. van Gaalen  wrote:
>> 
>>> This could be a simple solution: 
>>> 
>>> Starting each line with a special token.
>>> 
>>> In the example here it is the \\  double-backslash .  
>>> when the \\ appears in the first two columns of a source line, 
>>> this tells the compiler that it is a data line and that more might follow.
>>> the last line starting with \\ completes the data entry.
>>> 
>>> Here is an example of a string declaration with some XML
>>> (no escape sequences needed for “) 
>>> Of course it could be anything other kind of textual data as well.
>>> 
>>> let  str =  
>>> \\
>>> \\
>>> \\
>>> \\
>>> \\W3Schools Internal Note\n
>>> \\
>>> \\To: \n
>>> \\From: \n
>>> \\Message: 
>>> \\
>>> \\\n
>>> 

Re: [swift-evolution] multi-line string literals.

[Ted F.A. van Gaalen via swift-evolution]

This could be a simple solution: 

Starting each line with a special token.

In the example here it is the \\  double-backslash .  
when the \\ appears in the first two columns of a source line, 
this tells the compiler that it is a data line and that more might follow.
the last line starting with \\ completes the data entry.

Here is an example of a string declaration with some XML
(no escape sequences needed for “) 
Of course it could be anything other kind of textual data as well.

let  str =  
\\
\\
\\
\\
\\W3Schools Internal Note\n
\\
\\To: \n
\\From: \n
\\Message: 
\\
\\\n

Re: [swift-evolution] multi-line string literals.

[Ted F.A. van Gaalen via swift-evolution]

let purpleRain =// in remembrance to one of my favorite artists.
  “What’s wrong with concatenating string constants with “ +
  “plus-signs, like in this example? \n\n“+
  “I am quite happy with doing it this way. ”   +
  “No problem, kind regards\n”   +
  “TedvG” 

(not so active here in the coming 2-3 weeks.
In the process of moving from
www.illmensee.de  to  www.speyer.de )



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

Re: [swift-evolution] [Proposal draft] Enhanced floating-point protocols

[Ted F.A. van Gaalen via swift-evolution]

Hi Stephen


> Hi Erica, thanks for the feedback.
> 
>> On Apr 14, 2016, at 6:29 PM, Erica Sadun > > wrote:
>> 
>> * I do use % for floating point but not as much as I first thought before I 
>> started searching through my code after reading your e-mail. But when I do 
>> use it, it's nice to have a really familiar symbol rather than a big word.
> 
Agreeing completely with Erica here.

> 
>> What were the ways that it was used incorrectly? Do you have some examples?
> 
> As it happens, I have a rationale sitting around from an earlier (internal) 
> discussion:
> 
> While C and C++ do not provide the “%” operator for floating-point types, 
> many newer languages do (Java, C#, and Python, to name just a few).  
> Superficially this seems reasonable, but there are severe gotchas when % is 
> applied to floating-point data, and the results are often extremely 
> surprising to unwary users.
What is your definition of unwary users? Programmers that usually don’t work 
with floating point data? 
No gotchas or total flabbergasting astonishment with day to day floating point 
usage.

>  C and C++ omitted this operator for good reason.  Even if you think you want 
> this operator, it is probably doing the wrong thing in subtle ways that will 
> cause trouble for you in the future.
I don’t share this opinion at all.
> 
> The % operator on integer types satisfies the division algorithm axiom: If b 
> is non-zero and q = a/b, r = a%b, then a = q*b + r.  This property does not 
> hold for floating-point types, because a/b does not produce an integral value.
The axiom is correct of course, but only in a perfect world with perfect 
numbers. Not in real life.   **
Floats never represent integral values, if so then they were Integers.

>  If it did produce an integral value, it would need to be a bignum type of 
> some sort (the integral part of DBL_MAX / DBL_MIN, for example, has over 2000 
> bits or 600 decimal digits).
Impossible. E.g. one would need a planet covered completely 
with memory (even holographic quantum) units and even then 
you would not have enough storage to store (one) PI with all its decimals.
By the way most of PIs decimals are unknown as you know.
It could even be that memory units on all the planets in (this) 
the universe are even not enough to satisfy the storage need 
for just one PI.
 * Please read the Hitchhikers Guide To The Galaxy for more info on this 
interesting subject :o)
Of course, the last decimals of PI are …42. Dolphins know that, but they left 
long ago in the future *  
> 
> Even if a bignum type were returned, or if we ignore the loss of the division 
> algorithm axiom, % would still be deeply flawed.  
   % is not flawed. It’s just the real life precision limitations of the 
floating point type. Live with it.


> Whereas people are generally used to modest rounding errors in floating-point 
> arithmetic, because % is not continuous small errors are frequently 
> enormously magnified with catastrophic results:
> 
>   (swift) 10.0 % 0.1
>// r0 : Double = 0.0995 // What?!
As I have tried to explain in more detail before:
This is perfectly normal, acceptable  and expected, because,
whether you like it or not, that is the exactly? the nature of 
floating point numbers stored in a computer
(well, at least in this age)  they’re not precise,
but in context precise enough voor most purposes in scientific 
and engineering applications.
If you want to work with exact values e.g. for representing money,
then use an appropriate numerical type 
or roll your own, make a struct for it.

Swift is poor in this because it only offers Integer and Floating point 
numerical types,
not Fixed Decimal (Like e.g. in PL/1 and C#) 
also its Ranges and iterations are with Integers only and
going in one direction only.
 
> 
> [Explanation: 0.1 cannot be exactly represented in binary floating point; the 
> actual value of “0.1” is 
> 0.155511151231257827021181583404541015625.  Other than that 
> rounding, the entire computation is exact.]
no, it's not. or at least you can’t count on that. especially when intermediate 
expressions (with floats) are involved.

** (to all, not meant cynically here, and with all due respect:
If you don’t value floats and understand their purpose and place,
please go programming for a half year or so in an industrial/engineering 
workshop.
You’ll notice that these precision issues you are writing about are mostly 
irrelevant.
E.g. You could theoretically calculate the length of a steel bar for a bridge 
(the hardware one :o)
exactly to 0.0001 or so,  but the bar in question would only 
coincidentally have
this exact value. For instance thermal expansion will be much larger. 
http://www.engineeringtoolbox.com/thermal-expansion-metals-d_859.html 

It’s all a matter of magnitude in the context/domain of what one is 

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

[Ted F.A. van Gaalen via swift-evolution]

> Say you wanted to stride through a singly-linked list, it would actually be 
> beneficial to support only forward strides, the same is true of sequences, as 
> you either may not know what the endpoint is, or would have to step through 
> the whole sequence to find it (plus buffer every value in order to do-so 
> safely).
What if you are already somewhere in the middle (perhaps landed there by means 
of some other reference/link) of that linked list and want to stride backward? 


>> A consistent behavior with signed distances is so important that we are 
>> currently struggling with an interesting issue with floating point types, 
>> which is that due to rounding error 10.0 + a - a != 10.0 for some values of 
>> a.
Of course ! 
This is known (in computer domain) since ca. 1938.. (Konrad Zuse, with 22-bit 
floats) 
(btw I am glad that computer development in this critical war times especially 
in
nazi-Germany was extremely slow, relatively speaking, just imagine...) 

So, this should come as no surprise. 
Precision loss occurs with all arithmetic operations on floats. 
(in the above case probably the intermediate 
expression evaluation around the  !=  ,  
Compiler optimization may also cause
even further reduction of floating point precision )

Obviously, when working with floating point numbers 
one must always be aware of this and design/program 
accordingly.  This should become second nature.

E.g. it is perfectly acceptable and known (also in classical for-loops) 
that  
(0.0…1.0).by(0.1)
is not guaranteed to reach the humanly expected value of 1.0.

Due to the nature of what mostly is done in the floating point numbers domain, 
this does not often cause problems (e.g like working with a slide ruler) 

if it is important to reach the “expected end” then one could
-add a precision loss compensating value like so 
  (v1…v2 + 0.1) 
-or generate the desired float sequence within an integer loop **

The whole point with stride() here is perhaps because the attempt
to treat Continuous Data (floats)   as   Discrete Data (Integers) ?  

What about range operator?   
   with floats,  (a…b)  will never work correctly(accept this as normal, 
inherent with floats) 

I’d suggest 
(a<.

[swift-evolution] Classical For Loop

[Ted F.A. van Gaalen via swift-evolution]

Although it was my intention,
currently I am *not* considering making an official proposal 
for such a classical for loop because there is not enough 
interest, or so it seems. 

Also, because it should be imho obvious why
such a statement should be an integral part (as it was) Swift,
in particular for floating point iterations.

Kind Regards

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Ted F.A. van Gaalen via swift-evolution]

Hi All.

nearly no one has yet reacted on my mail, echoed here again,

which leaves by me the following questions pending:

-does what I define and describe completely cover all the required functionality
 for ranges for all numerical types?

-does it eliminate the need for using “Stride(...)”  at least for numerical 
scalars?

-combined with for .. in…  , is it an adequate replacement for the  classical 
for loop?

-can we eliminate  half open operators? Because imho that would simplify things 
greatly.
  -to which text of Dijkstra is this related?  


Objections? 
improvements? 
Things that I have missed? 
Feasibility? 
Implementable?

Thanks
TedvG





> On 06.04.2016, at 22:43, Ted F.A. van Gaalen  wrote:
> 
> 
> 
> Hi Erica, Dave
> 
> Based on what I’ve (not all) read under this topic: 
> 
> I’d suggest a more complete approach:
> 
> Ranges should support:  (as yet not implemented) 
> 
> - All numerical data types (Double, Float, Int, Money***, Decimal*** ) 
> - An arbitrary increment or decrement value.
> - Working in the complete  - + numerical range
> - Allow traversing in both   - + directions.
> 
> 
> 
> The basics:
> 
> (v1…v2).by(v3) // this still is readable. and can be optimized by the 
> compiler (predictable sequence)
> 
> Rules:
> 
> v1, v2, v3  are any numerical type scalar type  
> v1, v2, v3  must have the same numerical type.
> v1 >  v2:   is allowed and correctly evaluated.  e.g. 
> (8.0…-3.14159).by(-0.0001) 
> 
> 
> The  ..<  half open operator is no longer allowed.   write e.g.   
> 0...ar.count - 1
> 
> "by(…)”  is obligatory with floating point range.
> 
>the default “by(…)” value of 1 makes sense only with integer 
> ranges.
> 
> 
> valid examples:
> (5…9)// 5 6 7 8 9 Integer range without “by” 
> defaults to 1 as increment value.
> (1...10).by(2) // 1 3 5 7 9.
> (2...10).by(2) // 2 4 6 8 10.
> (4…-4).by(-2) // 4  2 0 -2 -4 .// runs backwards  
> <<<
> (30..-10).by(-2)// 30 28 26 24 22 ….. -10.
> (10...0).by(-3)  // 10 7 4 1. 
> 
> (12…-10) // is valid, but returns empty because default 
> increment value = 1
> 
> (12.0…-12.0).by(-1.5)   // 12.0  10.5  9.0….  // of course 
> with float imprecision
>
>
> 
>invalid examples:
> 
>(23.0..<60.5).by(0.5) // half open ranges are no  longer allowed 
> ** 
>   (23.0…60.5) // “ by"  is obligatory with floats.
>   (14...8).by(0.5)//  v1 v2 and v3 don’t have the same 
> numerical type 
> 
> 
> Half open ranges make no real sense (are not really useful) with floating 
> point values.
> and no sense at all with e.g (12..<-1)  afaics 
> 
> 
> At least for float iterations the increment value should not each time be 
> accumulated like
> v1 += v3;  v1 += v3;  v1 += v3;  ….   // causes float 
> number drift.
> but be freshly multiplied with each iteration, e.g. by using an internal 
> iteration counter
> like so:
> 
> v = v1 + v3 * i++; v = v1 + v3 * i++;  v = v1 + v3 * i++;  v = v1 + 
> v3 * i++; <<<
> 
> for reasons of precision.
> 
> If one has worked with floating point data more often
> awareness of its precision limitations become a second nature conscience. 
> E.g. it is perfectly acceptable and known (also in classical for-loops) that
> (0.0…1.0).by(0.1) is not guaranteed to reach the humanly expected value of 
> 1.0.
> This is normal. Due to the nature of what mostly is done in the
> floating point numbers domain, this does not often cause a problem
> (e.g like working with a slide ruler) 
> if it is important to reach the “expected end” then one could
> -add an epsilon value like so (v1…v2 + 0.1) 
> -generate the desired float sequence within an integer loop.
> 
> 
> The above “range” (imho) improvement makes the 
> stride.. function/keyword completely unnecessary.
> 
> Due to its ability to process reversed ranges as is, 
> the .reverse() is optional (no longer necessary in most cases,
> allowing the compiler to optimize without having to process 
> it like a collection.
> 
> 
> Now that we have a fully functional range, which can do all things desired, 
> one can
> then of course, pass this range without any change  to a collection based for 
> …  e.g.
> 
> for v in (v1…v2).by(v3)   // optionally add other collection 
> operators/filters/sorts here
> 
> (or in any other construct you might see fit)
>
> 
> This seems to be a reasonable alternative for
> 
> - the classical for ;; loop
> -the collection-free for-loop  
>  for v from v1 to v2 by v3
> 
> As you know, the latter is what I have been suggesting, 
> but seemingly does not find much support,
> 

Re: [swift-evolution] Feature proposal: Range operator with step

[Ted F.A. van Gaalen via swift-evolution]

Hi Milos

Yes,  (v1…v2).by(v3)  it can determine the going of either in  + or - direction,
but only at run time! because the contents of v1, v2, v3 are of course unknown 
at compile time. 
Ergo: it cannot expected be an absolute value.

however, I suggested (coded) that here on 4.3.2016…  Works in Playground Xcode 
7.3
look in the struct its “init”   where the direction is determined
by wether “from” or “to” is bigger” 
implemented like this  (and also with a floating point number tolerance)
(The struct should be numerical generic, but I didn’t manage to change it to 
generic,) 
Anyway, should be compilerized/hand coded in asm perhaps (I can’t do that)

TedvG

public struct StriderGenerator : GeneratorType
{
private let low: Double
private let high: Double
private var step : Double
private var tol  : Double

private var iterator  = 0

private let moveForward: Bool

private var done  = false


public init(from: Double, to: Double, by: Double, tolerance: Double)
{
step = by
if from < to
{
low  = from
high = to
moveForward = true
}
else
{
low  = to
high = from
moveForward = false
}
self.tol   = tolerance * 0.5  // center it.
}

/// return next value or nil, if no next
/// element exists.

public mutating func next() -> Double?
{
let current:Double
if done
{
return nil
}

if moveForward
{
current = low + Double(iterator) * step
}
else
{
current = high - Double(iterator) * step
}
iterator += 1


// done if exceeding low or high limits + tolerance

done = current > high   + tol  ||
   current < low- tol

if done
{
return nil
}
else
{
return current
}
}
}

public struct Strider : SequenceType   // Aragorn
{
private let start:  Double
private let end:Double
private let step:   Double
private let tol:Double

init(from: Double, to: Double, by: Double, tolerance : Double)
{
_precondition(by > 0.0 ,
"Init of struct Strider: 'by:...' value must be > 0.0.")
_precondition(abs(by) > tolerance,
"Init of struct Strider: 'by:...' value must be > tolerance.")
_precondition(tolerance >= 0.0,
"Init of struct Strider: tolerance:... value must be >= 0.0")

start = from
end   = to;
step  = by
tol   = tolerance
}

/// Return a *generator* over the elements of this *sequence*.

public func generate() -> StriderGenerator
{
return StriderGenerator(from: start, to: end, by: step, tolerance:  tol)
}
}

public extension Double
{

public func strider(to to: Double, by: Double, tolerance: Double ) -> 
Strider
{
return Strider( from: self, to: to, by: by, tolerance: tolerance)
}
}

print("Testing the new .strider extension")

let testvalues =
[
// fr: to: by:   tolerance:
[ 0.0, 5.0,1.0,0.0 ],
[-3.0, 4.0,0.12,   0.1 ],
[ 2.0,-1.0,0.34,   0.1  ],
[ 0.001,  -0.002,  0.0001, 0.1 ]
]

for parm in testvalues
{

print("==Stride from: \(parm[0]) to: \(parm[1]) by: \(parm[2]) 
tolerance: \(parm[3])\n")

for val in parm[0].strider(to: parm[1], by: parm[2], tolerance: parm[3])
{
print("\(val) ", terminator:"")
}
print("\n\n")
}




TedvG



> On 06.04.2016, at 23:15, Milos Rankovic <mi...@milos-and-slavica.net> wrote:
> 
> Hi Ted,
> 
>> that would imply the ‘by”value should/must always be an absolute value?
> 
> 
> In a way: Instead of `Strideable.Stride` I would suggest 
> `Strideable.Distance`.
> 
> At any rate, leaving the sign to be direction indicator makes it forever 
> necessary for everyone to make this counterintuitive metal gymnastics, since 
> most of the time in life we do not walk backwards, even when we are returning 
> back whence we came from!
> 
> What do you think?
> 
> milos
> 
> 
>> On 6 Apr 2016, at 21:34, Ted F.A. van Gaalen <tedvgios...@gmail.com 
>> <mailto:tedvgios...@gmail.com>> wrote:
>> 
>> Hello Milos,
>> Good question
>> was thinking about this too.
>> that would imply the ‘by”value should/must always be an absolute value?
>> however (if it is a var) it cannot be guaranteed to be + or - 
>> that’s why I thought to leave it as is.
>> ?
>> TedvG
>> 
>>> On 06.04.2016, a

Re: [swift-evolution] Feature proposal: Range operator with step

[Ted F.A. van Gaalen via swift-evolution]

G Typos… Sorry, here it is again: vital  correctionslook at<< 
<

Hi Erica, Dave

Based on what I’ve (not all) read under this topic: 

I’d suggest a more complete approach:

Ranges should support:  (as yet not implemented) 

- All numerical data types (Double, Float, Int, Money***, Decimal*** ) 
- An arbitrary increment or decrement value.
- Working in the complete  - + numerical range
- Allow traversing in both   - + directions.



The basics:

(v1…v2).by(v3) // this still is readable. and can be optimized by the 
compiler (predictable sequence)

Rules:

v1, v2, v3  are any numerical type scalar type  
v1, v2, v3  must have the same numerical type.
v1 >  v2:   is allowed and correctly evaluated.  e.g. 
(8.0…-3.14159).by(-0.0001) 


The  ..<  half open operator is no longer allowed.   write e.g.   
0...ar.count - 1

"by(…)”  is obligatory with floating point range.

   the default “by(…)” value of 1 makes sense only with integer ranges.


valid examples:
(5…9)// 5 6 7 8 9 Integer range without “by” 
defaults to 1 as increment value.
(1...10).by(2) // 1 3 5 7 9.
(2...10).by(2) // 2 4 6 8 10.
(4…-4).by(-2) // 4  2 0 -2 -4 .// runs backwards
  <<<
(30..-10).by(-2)// 30 28 26 24 22 ….. -10.
(10...0).by(-3)  // 10 7 4 1. 

(12…-10) // is valid, but returns empty because default 
increment value = 1

(12.0…-12.0).by(-1.5)   // 12.0  10.5  9.0….  // of course with 
float imprecision
   
   

   invalid examples:

   (23.0..<60.5).by(0.5) // half open ranges are no  longer allowed ** 
  (23.0…60.5) // “ by"  is obligatory with floats.
  (14...8).by(0.5)//  v1 v2 and v3 don’t have the same 
numerical type 


Half open ranges make no real sense (are not really useful) with floating point 
values.
and no sense at all with e.g (12..<-1)  afaics 


At least for float iterations the increment value should not each time be 
accumulated like
v1 += v3;  v1 += v3;  v1 += v3;  ….   // causes float 
number drift.
but be freshly multiplied with each iteration, e.g. by using an internal 
iteration counter
like so:

v = v1 + v3 * i++; v = v1 + v3 * i++;  v = v1 + v3 * i++;  v = v1 + v3 
* i++; <<<

for reasons of precision.

If one has worked with floating point data more often
awareness of its precision limitations become a second nature conscience. 
E.g. it is perfectly acceptable and known (also in classical for-loops) that
(0.0…1.0).by(0.1) is not guaranteed to reach the humanly expected value of 1.0.
This is normal. Due to the nature of what mostly is done in the
floating point numbers domain, this does not often cause a problem
(e.g like working with a slide ruler) 
if it is important to reach the “expected end” then one could
-add an epsilon value like so (v1…v2 + 0.1) 
-generate the desired float sequence within an integer loop.


The above “range” (imho) improvement makes the 
stride.. function/keyword completely unnecessary.

Due to its ability to process reversed ranges as is, 
the .reverse() is optional (no longer necessary in most cases,
allowing the compiler to optimize without having to process 
it like a collection.


Now that we have a fully functional range, which can do all things desired, one 
can
then of course, pass this range without any change  to a collection based for … 
 e.g.

for v in (v1…v2).by(v3)   // optionally add other collection 
operators/filters/sorts here

(or in any other construct you might see fit)
   

This seems to be a reasonable alternative for

- the classical for ;; loop
-the collection-free for-loop  
 for v from v1 to v2 by v3

As you know, the latter is what I have been suggesting, 
but seemingly does not find much support,
(because I received very little reactions) 
making it doubtful if I will ever make a proposal for this for loop.
Anyone out there should I stil do that? 

When one does not further extend the range
with filters like sort etc. the compiler can still optimize 
a collection-in-between out of the way.
(Thank you Taras, für das Mitdenken. :o)


**   note that a half open range would in most cases be unnecessary 
  if  collection indexes started with 1 instead of 0, e.g. someArray[1…10] 
 (but it’s too late to change that.) 
 “the color of the first apple?”vs
 “the color of the zeroth (0) ???  apple?”? Silly isn’t? 

*** possible future numerical “native” types 


It could be that (at least) partly something similar has already been suggested.
but so much is here of this topic that i can’t see the wood for the trees, so 
to speak.


Your (all) opinions are appreciated. 

kind regards, mit 

Re: [swift-evolution] Feature proposal: Range operator with step

[Ted F.A. van Gaalen via swift-evolution]

Hello Milos,
Good question
was thinking about this too.
that would imply the ‘by”value should/must always be an absolute value?
however (if it is a var) it cannot be guaranteed to be + or - 
that’s why I thought to leave it as is.
?
TedvG

> On 06.04.2016, at 22:18, Milos Rankovic <mi...@milos-and-slavica.net> wrote:
> 
> 
>> On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> v1 >  v2:   is allowed and correctly evaluated.  e.g. 
>> (8.0…-3.14159).by(-0.0001) 
> 
> If the range does not assume `start >= end`, is it still necessary to also 
> indicate the traversal direction with the sign of the step (`-0.0001`)?
> 
> milos

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

Re: [swift-evolution] Feature proposal: Range operator with step

[Ted F.A. van Gaalen via swift-evolution]

Hi Erica, Dave

Based on what I’ve (not all) read under this topic: 

I’d suggest a more complete approach:

Ranges should support:  (as yet not implemented) 

- All numerical data types (Double, Float, Int, Money***, Decimal*** ) 
- An arbitrary increment or decrement value.
- Working in the complete  - + numerical range
- Allow traversing in both   - + directions.



The basics:

(v1…v2).by(v3) // this still is readable. and can be optimized by the 
compiler (predictable sequence)

Rules:

v1, v2, v3  are any numerical type scalar type  
v1, v2, v3  must have the same numerical type.
v1 >  v2:   is allowed and correctly evaluated.  e.g. 
(8.0…-3.14159).by(-0.0001) 


The  ..<  half open operator is no longer allowed.   write e.g.   
0...ar.count - 1

"by(…)”  is obligatory with floating point range.

   the default “by(…)” value of 1 makes sense only with integer ranges.


valid examples:
(5…9)// 5 6 7 8 9 Integer range without “by” 
defaults to 1 as increment value.
(1...10).by(2) // 1 3 5 7 9.
(2...10).by(2) // 2 4 6 8 10.
(4…-4).by(2) // 4  2 0 -2 -4 .// runs backwards
(30..-10).by(-2)// 30 28 26 24 22 ….. -10.
(10...0).by(-3)  // 10 7 4 1. 

(12…-10) // is valid, but returns empty because default 
increment value = 1

(12.0…-12.0).by(-1.5)   // 12.0  10.5  9.0….  // of course with 
float imprecision
   
   

   invalid examples:

   (23.0..<60.5).by(0.5) // half open ranges are no  longer allowed ** 
  (23.0…60.5) // “ by"  is obligatory with floats.
  (14...8).by(0.5)//  v1 v2 and v3 don’t have the same 
numerical type 


Half open ranges make no real sense (are not really useful) with floating point 
values.
and no sense at all with e.g (12..<-1)  afaics 


At least for float iterations the increment value should not each time be 
accumulated like
v1 += v3;  v1 += v3;  v1 += v3;  ….   // causes float 
number drift.
but be freshly multiplied with each iteration, e.g. by using an internal 
iteration counter
like so:

v1 = v3 * i++;   v1 = v3 * i++;   v1 = v3 * i++;….

for reasons of precision.

If one has worked with floating point data more often
awareness of its precision limitations become a second nature conscience. 
E.g. it is perfectly acceptable and known (also in classical for-loops) that
(0.0…1.0).by(0.1) is not guaranteed to reach the humanly expected value of 1.0.
This is normal. Due to the nature of what mostly is done in the
floating point numbers domain, this does not often cause a problem
(e.g like working with a slide ruler) 
if it is important to reach the “expected end” then one could
-add an epsilon value like so (v1…v2 + 0.1) 
-generate the desired float sequence within an integer loop.


The above “range” (imho) improvement makes the 
stride.. function/keyword completely unnecessary.

Due to its ability to process reversed ranges as is, 
the .reverse() is optional (no longer necessary in most cases,
allowing the compiler to optimize without having to process 
it like a collection.


Now that we have a fully functional range, which can do all things desired, one 
can
then of course, pass this range without any change  to a collection based for … 
 e.g.

for v in (v1…v2).by(v3)   // optionally add other collection 
operators/filters/sorts here

(or in any other construct you might see fit)
   

This seems to be a reasonable alternative for

- the classical for ;; loop
-the collection-free for-loop  
 for v from v1 to v2 by v3

As you know, the latter is what I have been suggesting, 
but seemingly does not find much support,
(because I received very little reactions) 
making it doubtful if I will ever make a proposal for this for loop.
Anyone out there should I stil do that? 

When one does not further extend the range
with filters like sort etc. the compiler can still optimize 
a collection-in-between out of the way.
(Thank you Taras, für das Mitdenken. :o)


**   note that a half open range would in most cases be unnecessary 
  if  collection indexes started with 1 instead of 0, e.g. someArray[1…10] 
 (but it’s too late to change that.) 
 “the color of the first apple?”vs
 “the color of the zeroth (0) ???  apple?”? Silly isn’t? 

*** possible future numerical “native” types 


It could be that (at least) partly something similar has already been suggested.
but so much is here of this topic that i can’t see the wood for the trees, so 
to speak.


Your (all) opinions are appreciated. 

kind regards, mit freundlichen Grüssen, Met vriendelijke groeten, 
Sigh, why do we Dutch always have to speak the languages of the bigger 
countries :o) 
TedvG

> on Wed Apr 06 2016, Erica Sadun  

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Ted F.A. van Gaalen via swift-evolution]

Hi Taras

I’ve watched the WWDC15 video about Swift compiler optimization, read some more
in depth material about it. It is probably advanced in many aspects of 
optimization.
So, you might be correct to assume that the compiler can optimize
>  for(int i = x0; i In case I didn’t explain my reasoning clear enough, here is another attempt. 
> Swift already has a very powerful, compact tool that offers a strict superset 
> of the iteration semantics.
That is not (yet) the case, let alone a superset!

> I simply see no purpose into making the language more verbose and complicated 
> for no particular gain.

It doesn’t make the language more complicated, rather, the reverse is true.
If you want a less verbose language, learn APL, or J.
APL proves unintentionally the inverse relation between “verbose”and 
“complicated” :o) 

> What you do is argue for having two different syntactic styles for 
> accomplishing exactly the same thing,
> simply on the grounds of your personal dislike of one of them. 
It is not at all personal dislike, it is many years of die-hard experience 
with a multitude of programming languages and systems.
I don’t think in emotional terms about programming constructs but
solely about practical implications, usefulness, reliably and so on.

I assume this difference of opinion will remain...

 -
Coincidentally, today John Heerema, described here on swift-evolution 
exactly my point of view on these matters based on facts. 
read his text please. Thank you.
 -
I hope I am not too unfriendly here, Nothing personal. 
If I am in Zürich again it would be nice to discuss this with a beer. 
Although not so far from here, currently my finances prevent this.

Kind regards
Ted
www.ravelnotes.com

  == The problem is not what you add to a programming language
  == but what you remove!
  








> On 31.03.2016, at 14:59, Taras Zakharko  wrote:
> 
> 
>> On 31 Mar 2016, at 14:12, Ted F.A. van Gaalen  wrote:
>> 
>> Alas, I don’t understand you irritation, 
>> but it is your irritation, not mine.
> 
> Well, its quite simple: we are having a discussion here. You are claiming 
> that the collection-based iteration is inherently slower than a classical 
> numerical loop. This is incorrect. I have even sent around some C code that 
> uses different abstractions and shown that it compiles to the same machine 
> code. Yet you are consistently ignoring this. 
> 
>> Please note again, that “for ... in …”  always has 
>> some sort of collection type as its argument..
>> At run time, the content of a collection 
>> is in most cases unpredictable.
> 
> Again, incorrect. The simple collections that are relevant to this discussion 
> are based on trivial iterators that 

Re: [swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations

[Ted F.A. van Gaalen via swift-evolution]

Hello John
I subscribe completely to this point(s) of view!
TedvG



> Date: Sun, 3 Apr 2016 19:25:09 +
> From: John Heerema >
> To: "swift-evolution@swift.org " 
> >
> Subject: Re: [swift-evolution] Revisiting 0004,   0007 etc. - Swift
>   deprecations
> Message-ID:  >
> Content-Type: text/plain; charset="windows-1252"
> 
> Thanks to all those who thoughtfully responded to this post! The folks who 
> responded provided kind thoughts and advice.
> 
> Ross O’Brian asked if I was familiar with the original discussion for 0004 
> and 0007.
> 
> To answer: Yes, I read the discussions several times over a period of a few 
> weeks before writing anything myself. Unless the repo is somehow missing an 
> awful lot of discussion, I would say that both of these proposals received 
> startlingly little discussion at the time. These are very early proposals 
> (numbers 4 and 7), and were conducted before a lot of people (including me) 
> had any idea that feedback was being solicited.
> 
> My thoughts on these deprecations are aimed more at the human side of how 
> developers actually behave, than on the strict “desirability" of the 
> deprecated features.
> 
> Let’s take proposal 0004 – to deprecate the ++ and — operators.
> 
> A few years ago, I’ve have chimed in to say “sure, let’s deprecate those 
> things. += is more general and obvious”. But that’s how those of us who think 
> about orthogonality think.
> 
> On the human side, what do the human being who write code actually do?
> Human beings notoriously do not act in the way we think they “should”.
> 
> Lots of languages, like C, C++, C#, Objective C, Java, etc., already have 
> both the prefix and suffix versions of ++ and --.
> All of those language also allow developers to use += 1. So, each and every 
> one of the millions of people who use those languages already have a choice 
> of using any of:
> a = a + 1
> a += 1, or
> a++
> 
> So an enormous social experiment has already been done, and we can benefit 
> from it, if we are willing. Given that millions of people have already been 
> given the choice of using any of the three forms shown above, what do they 
> actually prefer to use? There are many, many millions of lines of extant code 
> that can be parsed to determine what developers actually use when they are 
> given the choice.
> 
> I’m pretty sure that everyone on this list already knows the answer, and it’s 
> not the choice we might think that all those millions of developers “should” 
> have made. Given a free choice, developers overwhelmingly chose to use ++ and 
> —. They predominately use the suffix version, but the prefix version is also 
> common. If you don’t believe me, it’s easy to find out for yourself. 
> Actually, I would encourage you not to believe me. Please conduct your own 
> experiment if you have access to a significant body of code. At a more 
> personal level, did you have to refactor your own code to eliminate them? Of 
> course it's easy to do, but why didn’t you make the “right” choice in the 
> first place?
> 
> So, why would we deprecate the option that developers overwhelmingly choose 
> to use?
> Is it “for their own good”? Let’s remember that most people resent being told 
> to do something “for their own good”.
> 
> There’s something inside most people’s brains that wants to make other people 
> do something “for their own good”. I’d argue that this applies in spades to 
> language designers. We want to make Swift even better than it already is (and 
> I think that it’s already pretty darn good).  So it’s really tempting to have 
> the compiler enforce doing the right thing.
> 
> But we also want other developers to make a voluntary choice to use Swift, 
> when they could just as easily stick with Objective C, C, Java, or whatever 
> they are using right now. At least, I hope that’s what everyone on this list 
> wants.
> 
> Or do we want just Swift to be the cool language that those of us in the “in” 
> club use, without necessarily wanting other people to join our exclusive 
> little club? The answer to that question affects the discussion.
> 
> Taras Zakharko suggests that Swift isn’t trying to appeal to everyone. 
> Perhaps not, but I hope that it does. We are long overdue for a modern 
> general purpose language that compiles to, and is interoperable with native 
> code. I think that Swift is great enough to be that language.
> 
> If we have already made a particular choice, and we’re used to defending our 
> choice as being the right one, it’s really hard for us to even imagine that 
> we might have made a decision that doesn’t further our eventual goal.  So, 
> what’s the goal for Swift? Is it to be the language that finally takes over 
> from C’s popularity? Or is it to be a specialized 

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Ted F.A. van Gaalen via swift-evolution]

Grüezi wohl Taras

you wrote:

> I find it quite irritating that you keep repeating these untrue facts. Again: 
> both for loops compile to exactly the same code. 


Alas, I don’t understand you irritation, 
but it is your irritation, not mine.

Please note again, that “for ... in …”  always has 
some sort of collection type as its argument..
At run time, the content of a collection 
is in most cases unpredictable.
Ergo: this implies that in these cases,
the compiler cannot optimize the collection 
part of the “for … in …” statement out of the way. 
In an attempt to overcome this restriction, 
it would need to analyze all entities that have 
influenced the content of the collection, 
which is virtually impossible.
 
I do not understand your aversion against 
the for loop I brought forward, as it does not 
conflict at all with the “for ... in …” construct 
and probably also does not stand in the way 
of possible future extensions that could be 
added to the "for in..” construct. 

E.g. For similar reasons one could be irritated by 
the brave attempts of some of us to supply 
most peculiar variants of “Strides", seemingly,
at least as seen from my limited perspective,
to compensate the loss of the classical for-loop’s
facilities...  
In spite of all this being very fascinating and 
creative, to me, this effort is comparable with
trying to climb the Eiffel tower, equipped
with boxing gloves and diving fins.
it could irritate me.. However it does not,
for the mere reason that I do not fully 
understand their motives and logical grounds...
Nevertheless, they might -or might not- 
have good reasons to do so, as we no 
doubt will find out sooner or later...
In any case, this does affect the collection-based
“for … in …” only, and has no impact on the 
“for v from v1 to v2 by vstep” 
that I am proposing. 



> Collection-based for loop can express exactly the same semantics, so why do 
> you need a new construct when you already have a perfectly good one to do the 
> job? 


For the simple reason that there are no collections involved: 
I have very clearly described and motivated it. 
Please read it again, thank you.

By the way, it is not a new construct as it has been
existing for decades.

I took the liberty to read about you on the internet. Interesting.

I’ve read that you have a degree in linguistics, 
which makes me assume that of all people, 
you’d understand that in most languages 
there are many different ways to express something,
and that the way to express or say something 
is mostly determined by contextual aspects... 
So in the light of this very specific knowledge
that you have, I fail to understand what your
objections are against the presence of 
two slightly different for-loop variants
that can co-exist easily and are effective,
each in its own different context?  

Last but not least, you might find this interesting:
(although I am almost sure you have read it before)

http://blog.oxforddictionaries.com/2014/09/george-orwell-newspeak/

and then most particularly in this text: 

“Newspeak goals and real-world ramifications”

I cannot completely clear myself from the association
of this with the removal of certain Swift language 
elements..


Met vriendelijke groeten.
TedvG


 

> On 31.03.2016, at 10:11, Taras Zakharko <taras.zakha...@googlemail.com> wrote:
> 
> 
>> On 30 Mar 2016, at 22:05, Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Again I need to emphasize very strongly that this for-loop really 
>> has absolutely 
>>  nothing, nada, zilch, niente, nichts, niets, niks, rien, zero, nenio,
>> to do with the: 
>> 
>> for i in stride(…. 
>> 
>> or any other for in… variant working with collections.
> 
> Of course it does. Collection-based for loop can express exactly the same 
> semantics, so why do you need a new construct when you already have a 
> perfectly good one to do the job? 
> 

>> 
>> but, once again - 
>> provided you don’t want to do other operations
>> on the generated collection before iterating -  
>> a collection is used here totally unnecessary, 
>> which puts a burden on performance because the contents 
>> of a collection are unpredictable 
> 
> I find it quite irritating that you keep repeating these untrue facts. Again: 
> both for loops compile to exactly the same code. 
> 
>> It is also tedious to write and (as a matter of my personal taste) downright 
>> ugly.
> 
> Right, because 
> 
>  for d in stride(from:10, to: 5, by: 0-.1, tolerance: 0.01) 
> 
> is that much more tedious to write than what you propose
> 
> Best, 
> 
>  Taras
> 
> 

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

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

[Ted F.A. van Gaalen via swift-evolution]

f Int32 to Double is fine, and Int16 to Float 
>>>>> might be as well, but I’m not certain if it’s a good idea or not, as it’s 
>>>>> not quite the same as just extending the value.
>>>> It simply would cause a float with less precision as an integer like 
>>>> 1 -becomes e.g - .99, (depending on magnitude, of course) 
>>>> but that is normal in a floating point domain; E.g.  also with: 
>>>>  var v:Double  = 1.0   //   Double to Double 
>>>> 
>>>> v would have the same imprecision… and could be anywhere between 
>>>> .9998…1.1  
>>>> (rough estimation, depending on magnitude and the floating point type 
>>>> used) 
>>>> 
>>>>> 
>>>>>> On 30 Mar 2016, at 14:57, Developer via swift-evolution 
>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>> 
>>>>>> What you describe, all those cases where one fixes losing precision by 
>>>>>> simply "ignoring it", that's part of why I'm hesitant about simply 
>>>>>> throwing in C-like promotion rules into any language.
>>>> 
>>>> E.g. if I assign an Int to a Double, then I know very well what I am doing.
>>>>  often occurring simple example here:
>>>>for i in 0..<10
>>>> {
>>>> dTemperature = dInterval * i / /   Double = Double 
>>>> * Int  (not possible yet in Swift)
>>>>foo(dTemperature)  
>>>>  }
>>>>  
>>>>   Here I still have to write: 
>>>>dTemperature = dInterval * Double(i)   
>>>> 
>>>>   However, Swift will accept: 
>>>>dTemperature = dInterval * 3// 3 inferred to 
>>>> Double. could be regarded as an implicit conversion? 
>>>> 
>>>>   
>>>> 
>>>>>>  Once you add implicit type coercions, even just between integer or 
>>>>>> floating point types, your language gains a hundred unspoken rules
>>>> Could you please explain these “unspoken rules” you mention more in 
>>>> detail?  
>>>> 
>>>>>> and little guard rails you have to cling to lest you slip and hit the 
>>>>>> next pitfall.
>>>> I am counting on the average intelligence of programmers.
>>>> 
>>>>>>  Though you may be dismissive of information loss, it is a serious issue 
>>>>>> in coercions, and one with implications that are never completely 
>>>>>> grokked by experts
>>>> In practice, the implications/effects/behavior of a programming language 
>>>> cannot be fully predicted and understood, there are simply too many 
>>>> possibilities, 
>>>> Functional Programming attempts to solve this, trying to make/do 
>>>> everything mathematically 
>>>> correct but fails for the aforementioned reason.
>>>> 
>>>>>> and serve as yet another hindrance to novices trying to adopt the 
>>>>>> language. 
>>>> I don’t agree here. Even novices should have a good understanding 
>>>> of the basic data types of a programming language,
>>>> Also note that  concepts of integer, natural, rational, irrational numbers 
>>>> etc.
>>>> is very basic mathematics as learned in high school. 
>>>> or your country’s equivalent education. 
>>>> 
>>>> 
>>>> So aDouble = anInt  should -in the programmer’s mind- 
>>>> appear as an explicit conversion, that is, he/she should realize the 
>>>> consequences. 
>>>> The same applies also doing it explicitly like so:
>>>>
>>>>  aDouble = Double(anInt)
>>>> Same effect: even a fool can use this as well and not knowing the 
>>>> implications.
>>>> 
>>>> 
>>>>>> 
>>>>>> So, I don't think coercion under this scheme is the complete 
>>>>>> end-all-be-all solution to this problem, [though it may certainly feel 
>>>>>> right].  Sure, it is always defined behavior to "downcast" a value of a 
>>>>>> lower bitwidth to one of a higher bitwidth, but to dismiss Int -> Float, 
>>>>>> Float -> Int,
>>>> I wrote that I don’t want implicit 

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

[Ted F.A. van Gaalen via swift-evolution]

s a hundred unspoken rules
>> Could you please explain these “unspoken rules” you mention more in detail?  
>> 
>>>> and little guard rails you have to cling to lest you slip and hit the next 
>>>> pitfall.
>> I am counting on the average intelligence of programmers.
>> 
>>>>  Though you may be dismissive of information loss, it is a serious issue 
>>>> in coercions, and one with implications that are never completely grokked 
>>>> by experts
>> In practice, the implications/effects/behavior of a programming language 
>> cannot be fully predicted and understood, there are simply too many 
>> possibilities, 
>> Functional Programming attempts to solve this, trying to make/do everything 
>> mathematically 
>> correct but fails for the aforementioned reason.
>> 
>>>> and serve as yet another hindrance to novices trying to adopt the 
>>>> language. 
>> I don’t agree here. Even novices should have a good understanding 
>> of the basic data types of a programming language,
>> Also note that  concepts of integer, natural, rational, irrational numbers 
>> etc.
>> is very basic mathematics as learned in high school. 
>> or your country’s equivalent education. 
>> 
>> 
>> So aDouble = anInt  should -in the programmer’s mind- 
>> appear as an explicit conversion, that is, he/she should realize the 
>> consequences. 
>> The same applies also doing it explicitly like so:
>>
>>  aDouble = Double(anInt)
>> Same effect: even a fool can use this as well and not knowing the 
>> implications.
>> 
>> 
>>>> 
>>>> So, I don't think coercion under this scheme is the complete 
>>>> end-all-be-all solution to this problem, [though it may certainly feel 
>>>> right].  Sure, it is always defined behavior to "downcast" a value of a 
>>>> lower bitwidth to one of a higher bitwidth, but to dismiss Int -> Float, 
>>>> Float -> Int,
>> I wrote that I don’t want implicit conversion for Float -> Int. 
>>>> and Double -> Float, etc. coercions as mere trifles is an attitude I don't 
>>>> want enshrined in the language's type system.
>>>> 
>> Could you give me an example where Double -> Float is problematic (apart 
>> from loosing precision) ? 
>> 
>>>> Perhaps there is a middle ground.  Say, one could declare conformance to a 
>>>> special kind of protocol declaring safe implicit convertibility (see: 
>>>> Idris' solution of having an `implicit` conversion mechanism).
>> Please spare me from this kind of contraptions.
>> 
>>   -=side note: =-
>> Thanks for bringing Idris to my attention. Investigating... 
>> Idris is a FP language. I am not against it, but to me, FP is almost 
>> unreadable.
>> I doubt if I will ever use it.  
>> I use strictly OOD/OOP. It’s natural. Like in Smalltalk. Proven. Solid.
>> For now, the only reason I use protocols in Swift are to accommodate  
>> delegating/callbacks.
>>   -= end side note =- 
>>  
>> 
>> 
>>>> Or perhaps a good first step may be to not deal with information loss at 
>>>> all, and only keep the parts of this proposal that are always defined 
>>>> behavior.
>> To me, there is no unintended information loss, because I know what I am 
>> doing regarding implicit conversion.
>> Then again, in all the cases for which I suggested implicit data type 
>> conversion, there is no data loss (apart from precision)
>> 
>> TedvG
>> 
>>>> 
>>>> ~Robert Widmann
>>>> 
>>>> 2016/03/30 8:01、Ted F.A. van Gaalen via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ:
>>>> 
>>>>> Currently, one has to deal with explicit conversion between numerical 
>>>>> types,
>>>>> which in many cases is unnecessary and costing time to code 
>>>>> for things that are quite obvious,
>>>>> and cluttering the source, making it less readable.
>>>>> 
>>>>> Especially dealing all the time with often unavoidable intermixing 
>>>>> of floating point types CGFloat, Float, and Double 
>>>>> is really very annoying. 
>>>>> 
>>>>> Conversion beween floating point types is always harmless as 
>>>>> floating point types are essentially the same. 
>>>>> They differ only in precision.
>>>>

Re: [swift-evolution] A (better) Swift Equivalent For The Classical For-Loop With Numeric Scalars

[Ted F.A. van Gaalen via swift-evolution]

I still would like to see this new for-loop statement be implemented in the 
next Swift version

 Examples:
 for v from 0.5 to 30.0 by 0.3// floating point types
 for v from 0 to 100 by 5   // Integer
 for v from 12.0 to -10.0 by -2  // Floating points backward 

the “by …” clause is optional for Ints only 


As previously written, a tolerance factor could also be implemented as optional,
allowing to “end on a humanly accepted boundary” so like in this example
the highest loop value would be 10.0 (+/- ca. 0.1) , not 9.9 :  
  
 for v from 0.0 to 10.0 by 0.1 tolerance 0.001 

// the “tolerance ..” clause is optional and allowed for floating point vars 
only


Again I need to emphasize very strongly that this for-loop really 
has absolutely 
 nothing, nada, zilch, niente, nichts, niets, niks, rien, zero, nenio,
to do with the: 

for i in stride(…. 

or any other for in… variant working with collections.

However inexplicably, in the previous discussions, a lot of people ***
tried desperately to replace this simple but precious gem, 
a miracle of astonishing beauty:   (sorry, got carried away a bit :o) 
  
for v from v1 to v2 by vstep 
 
with the collection based 

for in ….

The for in… is wonderful for collection based iterations, I use it 
all the time like
for thing in things // etc.



for d in 10.0.stride(to: 5.0, by: -0.1)
{
print(d)
}


but, once again - 
provided you don’t want to do other operations
on the generated collection before iterating -  
a collection is used here totally unnecessary, 
which puts a burden on performance because the contents 
of a collection are unpredictable 
It is also tedious to write and (as a matter of my personal taste) downright 
ugly.

Imho this looks a whole lot better and can also be very efficiently compiled: 

for d from 10.0 to 5.0 by -0.1 tolerance 0.01
{
print(d)
}


   !!! **
  Important is to see that this “for…”  is in fact
  a convenience solution for  “while” and “repeat” constructs: 
  and thus a totally different beast compared to the   "for in…” ! 
  *
var d = 10.0   
var v = 0.0
let step = 0.1

while d > 5.0 
{ 
print(d)
d -= step
}


The above is a bare minimum “while” equivalent
for the above for-loop, but still tedious to write!

What more can I write to convince? 


*** Please tell me if I am wrong, but: 
I am inclined to think that Functional Programming Minded
Colleagues are trying to push persistently their 
(mathematically correct?)  way of thinking upon Swift, 
thereby ignoring that Swift is and should remain a 
general purpose programming language.


TedvG
www.ravelnotes.com

@Erica,

Erica, as I seem to remember, You wrote somewhere
that Stride is broken, but the "10.0.stride…” example
above works perfectly well in Swift 2.2. playground.

So, what do you regard as wrong with it?
(apart from in some cases needing to specify an 
epsilon(tolerance) value? ) 



  














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

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

[Ted F.A. van Gaalen via swift-evolution]

 this kind of contraptions.

  -=side note: =-
Thanks for bringing Idris to my attention. Investigating... 
Idris is a FP language. I am not against it, but to me, FP is almost unreadable.
I doubt if I will ever use it.  
I use strictly OOD/OOP. It’s natural. Like in Smalltalk. Proven. Solid.
For now, the only reason I use protocols in Swift are to accommodate  
delegating/callbacks.
  -= end side note =- 
 


>> Or perhaps a good first step may be to not deal with information loss at 
>> all, and only keep the parts of this proposal that are always defined 
>> behavior.
To me, there is no unintended information loss, because I know what I am doing 
regarding implicit conversion.
Then again, in all the cases for which I suggested implicit data type 
conversion, there is no data loss (apart from precision)

TedvG

>> 
>> ~Robert Widmann
>> 
>> 2016/03/30 8:01、Ted F.A. van Gaalen via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ:
>> 
>>> Currently, one has to deal with explicit conversion between numerical types,
>>> which in many cases is unnecessary and costing time to code 
>>> for things that are quite obvious,
>>> and cluttering the source, making it less readable.
>>> 
>>> Especially dealing all the time with often unavoidable intermixing 
>>> of floating point types CGFloat, Float, and Double 
>>> is really very annoying. 
>>> 
>>> Conversion beween floating point types is always harmless as 
>>> floating point types are essentially the same. 
>>> They differ only in precision.
>>> 
>>> Therefore, I would recommend allowing the following implicit type 
>>> conversions:
>>> 
>>> -between all floating point types e.g. Double, Float, CGFloat  
>>> 
>>> -from any integer type to floating point types
>>> 
>>> -Also, personally, I wouldn’t mind assigning from a float to a (signed) 
>>> integer
>>> because I know what I am doing: that the fraction is lost 
>>> and that assigning a too large float to an Integer would then cause 
>>> a run time error, which I can try/catch, of course. 
>>> 
>>> -from unsigned integer to signed integer   
>>> (nothing is lost here, but overflow should cause a run time error) 
>>> 
>>> but no implicit conversion for:
>>> - from integer to unsigned integer   (loosing sign here)
>>> - from a larger integer type to a smaller one e.g.   Int32 <- Int64   
>>> (truncation)  
>>> 
>>> Note however, that the compiler should issue warnings 
>>> when you do implicit conversions, but these warnings 
>>> are for most programmers of the “Yeah I know, don’t bug me.”
>>> type, so one should be able to switch off these type of warnings.
>>> 
>>> Even a programmer with little experience simply knows 
>>> that bringing integers into the floating point domain 
>>> causes precision loss. 
>>> He/she also knows that assigning a Double to a smaller floating
>>> point type also cause precision loss.  
>>> the reverse is not true.
>>> 
>>> 
>>> Very much interested in your opinion!
>>> 
>>> 
>>> N.B. the above does not yet include 
>>> the fixed decimal numerical type as this type is not yet
>>> available in Swift.  However, it should be  implemented 
>>> *as soon as possible*  because the fixed decimal type 
>>> is really needed for applications working with financial data!
>>> E.g. 
>>> var depositPromille: Decimal(10,3)
>>> typealias  Money = Decimal(20,2) 
>>>   
>>> For more info on how this could be implemented
>>> in Swift. please read a PL/1 manual, ( i grew up in this world)
>>> like this one: 
>>> 
>>> http://www.ibm.com/support/knowledgecenter/#!/SSY2V3_4.3.0/com.ibm.entpli.doc_4.3/lr/preface_plugin.htm
>>>  
>>> <http://www.ibm.com/support/knowledgecenter/#!/SSY2V3_4.3.0/com.ibm.entpli.doc_4.3/lr/preface_plugin.htm>
>>> 
>>> especially under sub-topic “Data elements” 
>>> 
>>> (however, don’t take everything for granted, PL/1 is still a very young 
>>> language :o) 
>>> Unfortunately OOP never made it into PL/1 because with it, it would be 
>>> nearly perfect.)
>>> 
>>> Should I make a new swift-evolution topic for fixed decimal?
>>> 
>>> Kind Regards
>>> TedvG
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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] Implicit Type Conversion For Numerics Where Possible.

[Ted F.A. van Gaalen via swift-evolution]

Hi Tino

> On 30.03.2016, at 15:07, Tino Heth <2...@gmx.de> wrote:
> 
> Sometimes, it's definitely desirable to have implicit conversion… but 
> sometimes, it's not, so I think the current behavior is good.
> I guess most of us have a zero tolerance policy for warnings, so those would 
> be treated like the current errors.
> 


e.g. this should never be a problem at run time:
   aFloat = anInteger
neither is this: 
   aCGFloat = aDouble   

A warning is just that: a warning. simply notify the programmer, just in case 
he/she does not fully understand the implications..

Eg. in PL/1 these are not warnings but Information type messages.

  
> It is possible to define operators that take numerics with different types as 
> a workaround, and imho it wouldn't hurt to have a module that implements 
> those operations.
Imho, that would add to much noise to Swift 

You could of course handle conversion errors with a try/catch.


There is also extensive info how implicit data type conversion could be handled 
here:

http://odl.sysworks.biz/disk$vaxdocsep953/decw$book/d3ndaa10.p77.decw$book
(it is relatively new, from 1992, conversion rules of ca. 1970, but don’t let 
that bother you) 

I’ve worked with many other languages too, but most of my reference 
material is from PL/1,the parent of all procedural programming languages. 

However writing a proposal with 
“Replace Swift by PL/1 and add OOP features”   
goes perhaps a bit to far :o) 

TedvG



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