macOS Show me a 'Hello, World!' in Swift

[Amazing Iceman]

[...]There shouldn't be any semantic difference between a=b, a = b, a= b and a =b as far as I can tell.

The problem is that the last two will give you an error in Playground.
I don't believe this problem is due to a semantics violation, but to an unfinished and buggy code parser in Playground (I still haven't tried compiling anything; I've been very busy lately, not much time left to learn Swift and experiment more with it).
This problem should go away in future releases of Xcode

----------

Playground is simply buggy as hell...

Yes it is. Sometimes it seems to have an internal process running lose that eats resources (CPU) like crazy! The solution is to close and restart Xcode.

BTW, what's the build number you are using? Is it the one released at WWDC?

 

[subsonix]

The problem is that the last two will give you an error in Playground.
I don't believe this problem is due to a semantics violation,

What exactly do you mean. The four statements should have the same meaning, but apparently they don't.

 

[Dranix]

Yes it is. Sometimes it seems to have an internal process running lose that eats resources (CPU) like crazy! The solution is to close and restart Xcode.

BTW, what's the build number you are using? Is it the one released at WWDC?

I use 6A215l - Should be the one from WWDC, no new builds since then, imo.

 

[pstoehr]

Ahoi,

The problem is that the last two will give you an error in Playground.
I don't believe this problem is due to a semantics violation, but to an unfinished and buggy code parser in Playground (I still haven't tried compiling anything; I've been very busy lately, not much time left to learn Swift and experiment more with it).
This problem should go away in future releases of Xcode

this is not a problem of PlayGround, the Swift compiler generates the same error messages

Best regards
Peter

 

[Dranix]

Ahoi,

this is not a problem of PlayGround, the Swift compiler generates the same error messages

Best regards
Peter

Could you open a Radar for it?

 

[iSee]

The Swift book mentions that white space is used to determine if an operator is postfix or prefix, which makes sense in the case of the ++ operator for example, but what is the difference between a postfix or prefix assignment operator. There shouldn't be any semantic difference between a=b, a = b, a= b and a =b as far as I can tell.

I think Swift's design is that it specifically doesn't make semantic assumptions about specific operators, as you suggest it should.

It's not what I'm used to, but there's some logic to it. (I guess all I can say is I haven't formed an opinion about one way or the other yet).

If the worst problem this causes is that you have to put spaces between = and its operands (and between other infix operators and their operands) or else suffer compiler errors, then I'm OK. That's actually a good thing for readability (in a minor way).

 

[subsonix]

I think Swift's design is that it specifically doesn't make semantic assumptions about specific operators, as you suggest it should.

Of course it does, all languages does, if they did not it would not be possible to express anything. Individual token are combined into statements that are either valid or not, according to some rules or a grammar.

Edit: on your last point, that this is intentional. It wouldn't actually affect me much since I separate the assignment operator with space, but it would still be a bit strange, I still haven't figured out what the purpose is of a pre or postfix assignment operator, in it's normal use. Can someone else come up with something.

 

[ArtOfWarfare]

Edit: on your last point, that this is intentional. It wouldn't actually affect me much since I separate the assignment operator with space, but it would still be a bit strange, I still haven't figured out what the purpose is of a pre or postfix assignment operator, in it's normal use. Can someone else come up with something.

You can write your own operators, so maybe you can come up with something valid on your own. I can't, personally.

 

[subsonix]

You can write your own operators, so maybe you can come up with something valid on your own. I can't, personally.

Yeah, but that's why I said "in normal use", if you overload the assignment operator for your own class then it can mean anything.

 

[iSee]

Of course it does, all languages does, if they did not it would not be possible to express anything. Individual token are combined into statements that are either valid or not, according to some rules or a grammar.

Edit: on your last point, that this is intentional. It wouldn't actually affect me much since I separate the assignment operator with space, but it would still be a bit strange, I still haven't figured out what the purpose is of a pre or postfix assignment operator, in it's normal use. Can someone else come up with something.

What I mean is:
- A Swift operator can be used in an infix, postfix or prefix context
- Semantics are defined independently for each context.
- Swift uses separating whitespace to distinguish the context an operator is used in.
- These general rules are the same for all operators. = is no different than ++

Of course, they do go on to define semantics for specific operators in specific contexts. (And where they leave it undefined, the compiler generates an error... like it would if you called a function that doesn't exist.)

BTW, I didn't really mean to suggest disallowing foo= and =foo was intentional. I don't know. My best guess is that this was just an accidental result of choosing the rules above, which they accepted because, while a little unexpected compared to other common C-like languages, is pretty much unobjectionable.

 

[subsonix]

What I mean is:
- A Swift operator can be used in an infix, postfix or prefix context

Show an example of pre/postfix assignment operator that does something different than assign the value to the right to the variable on the left.

- These general rules are the same for all operators. = is no different than ++

++ actually make sense in a pre/postfix context.

BTW, I didn't really mean to suggest disallowing foo= and =foo was intentional. I don't know. My best guess is that this was just an accidental result of choosing the rules above, which they accepted because, while a little unexpected compared to other common C-like languages, is pretty much unobjectionable.

It would still be intentional, as accepting the consequences of a design choice. But regardless of that, it still wouldn't force this behavior since it would be possible to use the same implementation for pre/post/infix assignment as far as I can tell.

 

[iSee]

Show an example of pre/postfix assignment operator that does something different than assign the value to the right to the variable on the left.

prefix and postfix operations have only one operand. There aren't two operands to assign the value of one to the other. If you use one between two operands with nothing else, I think that's just an invalid expression. (Well, if there's some way to put two valid expressions end-to-end with just a space in between and still form a valid Swift construct I can't think of it.)

To be clear: I'm just explaining how I think Swift is defined. I'm not saying it's good (or bad) or better (or worse) than the way some other languages are defined.

 

[subsonix]

prefix and postfix operations have only one operand. There aren't two operands to assign the value of one to the other. If you use one between two operands with nothing else, I think that's just an invalid expression. (Well, if there's some way to put two valid expressions end-to-end with just a space in between and still form a valid Swift construct I can't think of it.)

Yes, but there is no use for the pre/postfix "=" yet. I was thinking of something looking like this: a= b, a =b. As pstoehr mentioned, the error message is "Prefix/postfix "=" is reserved".

 

[pstoehr]

Could you open a Radar for it?

Done

 

[Dranix]

Done

Danke dir