Compile error from v0.11.0 on / .filter() / casts give different sizes error

[Robert-M-Muench]

With every version > 0.10.1 I get a very strange casting error I don't understand:

alias typeof(windows_message_streams[WM_MOUSEMOVE].filter!(win => (win.wParam & MK_LBUTTON))) WM_MOUSEMOVE_LBUTTON_TYPE;
WM_MOUSEMOVE_LBUTTON_TYPE WM_MOUSEMOVE_LBUTTON_STREAM;
pragma(msg,typeof(WM_MOUSEMOVE_LBUTTON_STREAM));
pragma(msg,WM_MOUSEMOVE_LBUTTON_TYPE.sizeof);

>> FilterObservable!(__lambda39, SubjectObject!(OS_State))
>> 16LU

WM_MOUSEMOVE_LBUTTON_STREAM = cast(WM_MOUSEMOVE_LBUTTON_TYPE)(windows_message_streams[WM_MOUSEMOVE].filter!(win => (win.wParam & MK_LBUTTON)));
pragma(msg,typeof(WM_MOUSEMOVE_LBUTTON_STREAM));
pragma(msg,WM_MOUSEMOVE_LBUTTON_STREAM.sizeof);

>> FilterObservable!(__lambda7, SubjectObject!(OS_State))
>> 8LU

..\..\gui.d(317,104): Error: cannot cast expression filter(windows_message_streams[512u]) of type FilterObservable!(__lambda6, SubjectObject!(OS_State)) to FilterObservable!(__lambda39, SubjectObject!(OS_State)) because of different sizes
FilterObservable!(__lambda7, SubjectObject!(OS_State))

My code works with version v0.10.1

[Robert-M-Muench]

The first part is on module scope, the second part inside a constructor. When I use auto inside the constructor it works too, but that's not what I want.

[Robert-M-Muench]

I cross-checked the v0.10.1 and v0.11.0 and there is a big change in filter.d which leads to the problem shown.

[lempiji]

It was intentional to remove the Voldemort types in the filter, but not the side effect of changing size.
It will be related to the compiler operation, so I will examine it in detail.

By wrapping FilterObservable! XXX in Observable! T and handling it, you may be able to achieve the desired operation at the expense of a little overhead.

[Robert-M-Muench]

So, you are going to fix this?

I don't see how I can "wrap FilterObservable! XXX in Observable! T and handling it" can you give an example?

[lempiji]

So, you are going to fix this?

I still don't know if this can be fixed. It depends on the results of the survey we are going to do.

However, there is no future to remove the declaration of FilterObservable and FilterObserver.

can you give an example?

Well, There is an example using "observableObject".

rx/examples/mvvm-gtk-d/source/mvvm/model.d

Lines 9 to 26 in 0d8c52d

	private Observable!bool _canDecrementAge;
	private Observable!bool _canClear;
	private Observable!string _profile;
	this()
	{
	_name = new BehaviorSubject!string("");
	_age = new BehaviorSubject!int(0);
	_canDecrementAge = _age.map!(age => age > 0).distinctUntilChanged()
	.observableObject!bool();
	_canClear = combineLatest(_name, _age).map!(t => t[0] != "" || t[1] != 0)
	.distinctUntilChanged().observableObject!bool();
	_profile = combineLatest!((a, b) => formatProfile(a, b))(_name, _age).distinctUntilChanged()
	.observableObject!string();
	}

This is like the inputRangeObject function for the InputRange interface.

[Robert-M-Muench]

This problem still exists, and I'm lost what to do. The example doesn't help me at all. Don't understand how it solves the problem.

I don't understand what "survey" you reference too nor this part "no future to remove the declaration of FilterObservable and FilterObserver."

[Robert-M-Muench]

Ok, seems I somehow managed to get it to work like this:

alias typeof(windows_message_streams[WM_MOUSEMOVE].filter!(win => (win.wParam & MK_LBUTTON)).observableObject!OS_State()) WM_MOUSEMOVE_LBUTTON_TYPE;
WM_MOUSEMOVE_LBUTTON_TYPE WM_MOUSEMOVE_LBUTTON_STREAM;

WM_MOUSEMOVE_LBUTTON_STREAM = windows_message_streams[WM_MOUSEMOVE].filter!(win => (win.wParam & MK_LBUTTON)).observableObject!OS_State();

Not sure what kind of side-effect this has.

[aberba]

This problem still exists, and I'm lost what to do. The example doesn't help me at all. Don't understand how it solves the problem.

I don't understand what "survey" you reference too nor this part "no future to remove the declaration of FilterObservable and FilterObserver."

I think by survey, he meant researching into the problem to see how he can solve it.

And the future word should be a feature...probably he plans to remove FilterObservable and FilterObserver in the future.

I think since he translates with Google translate, there might be loss of some context.