Bug 436279 - Very surprising behaviour of calling something on the result of an if/else
Summary: Very surprising behaviour of calling something on the result of an if/else
Status: REOPENED
Alias: None
Product: Xtend
Classification: Tools
Component: Core (show other bugs)
Version: 2.6.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-31 08:15 EDT by Victor Noël CLA
Modified: 2014-06-01 12:15 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Noël CLA 2014-05-31 08:15:37 EDT
Hi,

I got this very surprising behaviour of xtend with the java generated code:

class BugsIfElse {
	
	def test() {
		val r = if (true) {
			1
		} else {
			2
		}.m
	}
	
	def m(int x) {
		x + 5
	}
	
}

generates to:

@SuppressWarnings("all")
public class BugsIfElse {
  public void test() {
    int _xifexpression = (int) 0;
    if (true) {
      _xifexpression = 1;
    } else {
      _xifexpression = this.m(
        2);
    }
    final int r = _xifexpression;
  }
  
  public int m(final int x) {
    return (x + 5);
  }
}

As you can see, the call to m is applied to the content of the else block, and not to the result of the complete if/else block.
Comment 1 Sven Efftinge CLA 2014-06-01 06:04:56 EDT
you call m on the block expression. That's how the precedence is defined.
You need to use parenthesis if you want to apply m on the if expression's result.

	def test() {
		val r = (if (true) {
			1
		} else {
			2
		}).m
	}
Comment 2 Victor Noël CLA 2014-06-01 07:19:37 EDT
Hi,

I know that yes, but the "bug" is that it is very surprising and can lead to errors not seen by the user.

It doesn't seem natural at all!

Maybe we could add a warning about it or prevent such situation from happening?
Comment 3 Sebastian Zarnekow CLA 2014-06-01 12:15:00 EDT
Maybe we could optionally validate MemberFeatureCalls in else-branches that have a block expression as their target? That validation could be refined if more of these irritations come up.

Reopened to discuss that issue.