Concatenate two textfield

let postString = "Email= "+Email.text+"&Password="+Password.text

What are `Email` and `Password` in your code?

but does not work

Describe what do you mean with does not work .

What have you done, what have you expect and what have you actually get?

Assuming Email and Password are instance properties of type UITextField and you are getting compile time error, you need to rewrite your code as:

    let postString = "Email= "+(Email.text ?? "")+"&Password="+(Password.text ?? "")

The `text` property of UITextField is of type String?, aka Optional<String>. You cannot directly concatenate optional values with Strings.

And does anyone have any clue why it's an optional? It'll never return nil from what I can tell.

If the user fails to input the data, it would in fact be nil. And nil isn't allowed for any sort of

assignment anymore. Even Objective-C chokes on nil return values from text fields and such.

That's incorrect. If I add a UITextField and never click in it, the text property will not be nil. If I click in it and enter nothing, it's still not nil.

Can you please tell me a use case where it would in fact be nil? I never check for the nil value, I always just add the ! to unwrap it and then check for empty string to determine no input.

It should return nil if you set it to nil. Sometimes you need to distinguish between "no value has been set" and the empty string.

Specifically, when assigning a value to a string or other data type. If the user has not input

a value, nil will be the result and since iOS 7 results in a crash in Objective-C.

A textfield for example neither is, nor is not, untill you attempt to use whatever it might

contain. No entry, nil.

That's kind of the point I was making, since iOS 7 at least, nil has not been safe for

assignments. Sure, you can assign nil or no value to something but, other methods

or classes choke. Serializing for writing out to a plist for example results in a crash

every time if any value is nil in the data being serialized.

Again, what you just said is NOT true. Create a simple test and you'll see. Drop a text field and a button on a view, and link the button to something that just checks whether textField.text is nil.

Run, click the button. It won't be nil. Now click in the text field and click the button. It won't be nil.

I have. An app on the store. When text fields returned nil and my app attempted to serialize

for writing to a plist, the app crashed. When those values were replaced by empty strings

there was no crash. This is not theory or belief. This is what is, since iOS 7.

We all have apps on the app store. What I'm trying to say is that for many revisions now, I have never been able to produce any case in which the text property of the textField will ever return a nil value.

I'm asking you to explicitly point out a specific case where it will happen so that I can see it and stop just assuming it will always have a value.

I just did. You need the value in the text field. If there is no value and you assign it to

a string and then attempt to serialize that string for writing to a plist, the result is a

crash 100% of the time. If, you replace the nil value with an empty string, the crash

does not occur.

In my particular case, the app has 3 textfields. When the user taps the done button

the contents of those text fields are stored in string variables which are written to

a dictionary and serialized for writing to a plist. If any of those values are nil, the

app crashes. This was not true, prior to iOS 7.

Now you're talking something slightly different. The "text" property will return an empty string. Whatever you're trying to do with it at that point might not like an empty string and crash, but the VALUE of the text property is the empty string, not the nil value. If you're writing to a plist, and you tried to use that as the key, for example, I can see you getting a crash.

What is an empty string?

Since iOS 7, an empty string is nil. Before iOS 7 it was an "" empty string.

Didn't try to use it for the key but the value. The key was a known string already.

NSError *errors=nil;

int tripS;

int tripE;

tripS = [tripStartMiles.text intValue];

tripE = [tripEndMiles.text intValue];

NSString *stringOne=dateCurrent.text;

NSString *stringTwo=theDestination.text;

NSString *stringThree=tripStartMiles.text;

NSString *stringFour=tripEndMiles.text;

NSString *stringFive=[NSString stringWithFormat:@"%i",(tripE - tripS)];

NSString *stringSix=[NSString stringWithFormat:@"%i",tripCompleted];

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory, NSUserDomainMask, YES);

NSString *documentsDirectory = [paths lastObject];

NSString *myPlistFile = [documentsDirectory stringByAppendingPathComponent:@"milemeter.plist"];

NSMutableDictionary *myDictionary =[[NSMutableDictionary alloc]initWithCapacity:6];

// Without these conditionals, crash after iOS 7.

if (stringTwo==nil)

stringTwo=@"Blank";

if (stringThree==nil)

stringThree=@"0";

if (stringFour==nil)

stringFour=@"0";

if (stringFive==nil)

stringFive=@"0";

if (stringSix==nil)

stringSix=@"0";

// end of conditionals

[myDictionary setObject:stringOne forKey:@"tripdate"];

[myDictionary setObject:stringTwo forKey:@"tripdestination"];

[myDictionary setObject:stringThree forKey:@"tripstart"];

[myDictionary setObject:stringFour forKey:@"tripend"];

[myDictionary setObject:stringFive forKey:@"triptotal"];

[myDictionary setObject:stringSix forKey:@"tripcompleted"];

if(!myDataSourceArray)

{

myDataSourceArray=[[NSMutableArray alloc] init];

}

[myDataSourceArray addObject:myDictionary];

[myDictionary release];

NSData *serializedSettings=[NSPropertyListSerialization dataWithPropertyList:myDataSourceArray format:NSPropertyListXMLFormat_v1_0 options:NSPropertyListImmutable error:&errors];

[serializedSettings writeToFile:myPlistFile options:NSDataWritingAtomic error:&errors];

errors = nil;

In every test I've done before and tonight, using Swift and iOS 9 (so maybe that changes something?) I get back a zero length string, not a nil value.