<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">C# lambda expressions can be used to initialize an expression tree. This is how C# avoids using strings to interface with "embedded languages" (most notably and very usefully SQL, but as I'm about to show it could help deal with layout constraints in Swift as well if we had them).<div class=""><br class=""></div><div class="">If we could use an @autoclosure in Swift to initialize an expression tree, we could do something like:</div><div class=""><br class=""></div><div class=""><div class=""></div></div><blockquote type="cite" class=""><div class=""><div class="">protocol ExpressionTreeConvertible {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>init(expression: ExpressionTree)</div><div class="">}</div><div class=""><br class=""></div><div class="">class NSLayoutConstraint: ExpressionTreeConvertible {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>init(expression: ExpressionTree) { /* magic */ }</div><div class="">}</div></div><div class=""><br class=""></div><div class="">let constraint: NSLayoutConstraint = view1.frame.width == view2.frame.width * 0.5 + 10.0</div></blockquote><div class=""><div class=""><br class="webkit-block-placeholder"></div><div class="">and not require an == overload that doesn't return a Boolean.</div><div class=""><br class=""></div><div class="">That's not necessarily in support of limiting operator overloading, though.</div><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 8 janv. 2016 à 05:41:53, Marcel Jackwerth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">Sorry in advance for that slightly esoteric case.<br class=""><br class="">From a quick survey of peers an overloaded == which returns some other<br class="">type than Bool isn't desirable (same goes for >=, <=, !=, &&, ||) and<br class="">should be forbidden (this would be the counter-proposal to this).<br class=""><br class="">However it allows interesting DSLs like creating layout constraints<br class="">with <a href="https://github.com/indragiek/SwiftAutoLayout" class="">https://github.com/indragiek/SwiftAutoLayout</a><br class=""><br class="">let layoutConstraint = view1.al_width == view2.al_width * 0.5 + 10.0<br class=""><br class="">Allowing to import these 'conflicting' operators closely to where the<br class="">DSL is actually used could hint other developers to that DSL and<br class="">wouldn't pollute the global scope of the ViewController for example.<br class=""><br class=""><br class=""><br class="">I thought about a syntactical solution quite a bit but I failed to<br class="">find something that looked right. So here's a syntax draft which is<br class="">exceptionally wrong:<br class=""><br class="">import SwiftAutoLayout without fancy operators<br class=""><br class="">func compareSomething() -> Bool {<br class=""> return view1.al_width == view2.al_width // will fail since not<br class="">Equatable, but al_width is known<br class="">}<br class=""><br class="">func createConstraints() -> [NSLayoutConstraints] {<br class=""> import fancy operators from SwiftAutoLayout<br class=""> return [view1.al_width == view2.al_width] // succeeds<br class="">}<br class=""><br class="">OR (probably an implementation nightmare)<br class=""><br class="">func createConstraints() -> [NSLayoutConstraints] {<br class=""> import SwiftAutoLayout<br class=""> return [view1.al_width == view2.al_width]<br class="">}<br class=""><br class=""><br class="">Opinions against the proposal:<br class="">- Module devs shouldn't overload those operators and modify the return<br class="">type but use ====, !===, <==, ==>, &&&, ||| instead - Swift should<br class="">prevent that devs from doing this then.<br class="">- Devs will learn over time that (==, <=, >=, !=) are just the same as<br class="">+ and - and will have a return type depending on the arguments.<br class="">- Module devs should keep operators in submodules. (But then get<br class="">cyclic dependencies if they want to use these operators in the core<br class="">themselves.)<br class="">- Users of DSL modules should move the DSL dependent code into a<br class="">different file where it isn't mixed with code that doesn't need the<br class="">DSL.<br class=""><br class=""><br class="">Releated are the explicit includes and excludes when importing Modules<br class="">in the "Beef Up Import" thread<br class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004553.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004553.html</a><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>