Sorry for delay, but it seems that there's more traffic on the list than
I can handle, and stuff gets buried. As you can see, pinging can help :)
On Mon, 2012-07-09 at 11:31 +0200, Alexander Kurtz wrote:
> Hi,
>
> On Fri, 2012-07-06 at 17:54 +0300, Tanu Kaskinen wrote:
> > does the vala compiler really do this kind of deduction?
>
> No, it doesn't:
>
> $ cat Demo.vala
> int foo(int a, string b = "", int c){
> }
>
> void main(){
> foo(1, 2);
> }
> $ valac Demo.vala
> Demo.vala:5.9-5.9: error: Argument 2: Cannot convert from `int' to `string'
> foo(1, 2);
> ^
> Compilation failed: 1 error(s), 0 warning(s)
> $
>
> However, the vala compiler actually does support reordering arguments,
> so it would theoretically be possible to group the default arguments at
> the end without changing the C-API or any runtime wrappers. I can
> rewrite the bindings to do that, but I'd actually prefer to keep them
> the way the are because
>
> * I want to stay as close as possible to the C-API to ease
> migration, avoid confusion and to make sure that the regular
> doxygen documentation can be used.
Fully agree with this.
> * I want to include as much information as possible from the
> doxygen documentation in the vala bindings. Vala allows me to
> explicitly tell the programmer where passing NULL is ok (via
> the ?-suffix). Similarly I wanted to include the information
> where passing NULL is actually the thing you probably want to
> do? (according to the doxygen documentation).
Is this a widely used convention in the Vala world? To me the "default"
parameters that however can't be used as real default parameters seem
strange and confusing. The programmer should read the full documentation
for the function anyway, so the benefit for these hints seem
questionable to me.
--
Tanu
