Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XMLElement.text will never be nil. #132

Closed
ainopara opened this issue May 14, 2017 · 3 comments
Closed

XMLElement.text will never be nil. #132

ainopara opened this issue May 14, 2017 · 3 comments

Comments

@ainopara
Copy link
Contributor

When implementing #131 , I found that the type of XMLElement.text can be changed to String from String? without modify the implementing.
That is confirmed by making change like this and it is compiled successfully: ainopara@8e225b7

@ainopara
Copy link
Contributor Author

ainopara commented May 14, 2017

As a result the last parts of description implementation of XMLElement is equilvalent of

if true {
    return "<\(name)\(attributesString)>\(text)</\(name)>"
} else {
    return "<\(name)\(attributesString)/>" // WARN: Will never be executed
}

drmohundro added a commit that referenced this issue May 14, 2017
Per issue #132, XMLElement can't be nil because of how the reduce
implementation works. Instead, it will be an empty string. I think this
makes more sense than allowing for nils anyway.

A lot of the suggestions mentioned on issue #84 are related to reducing
the number of nil checks as well, so this should help alleviate some of
that.
@drmohundro
Copy link
Owner

Good catch! It looks like this will result in a breaking change (anyone using the library will have to change from element.text! to just element.text), so it probably best belongs in the next major version (see #84).

I just pushed version-4.0-changes branch to begin tracking this change. I'd like to get some of the other features from #84 pulled in before I release the next major release.

Thanks again for noticing this!

@drmohundro
Copy link
Owner

FYI, this was resolved with 4.0.0 and #133. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants