World: r3wp

We could also say that only the first value is the default if it's 
a literal; any number of options in this line. The remaining issue 
is how to define a default datatype! value.

I think he was using a literal issue! there Max.

sorry that was just because n was a issue! datatype - I thought

ok.

like f: func [/opt string ["hello" string!]][print string]

just for 'word the order would be necessary

else it could be free - but this would be bad for the habit and learning

This is something we could mock up today, to see how we like it.

Michael, is your example different from what I posted last?  I see 
no difference...

no :-) I see.

but keeping with consistency, not having any : in there does not 
seem right.

where you wanna put the :

HA!  if the value is a set word?

as in f: func [/opt val: 4 [integer!]] [print val]

one problem could be how to handle
f: func [/opt a-word [integer!]][...]

actually I kind of like this also - and wouldn't cause interpretation 
problems

it is very consistent with the rest of REBOL IMHO

problem compared to 
f: func [/opt a-word [the-word]][...]

Gabriele said there might be issues with using a set word within 
the func spec block,  but if func really is a dialect... I don't 
see how.

so what was the reason against your last (and has been before) idea 
?

ok

in any case, some words should be reserved  (like 'return)

So Gregg what do you think?

I think either one of these last two options we've come up with could 
work. I want to think about it a bit more, and others may chime in 
as well. I'm wondering if the extra block approach as easy to do, 
and had good performance, where this may have a bigger impact, but 
I like this line of thinking much better.

as easy to do = was easy to do

I do think that the set word approach is more approachable and much 
more readable... do you agree?

I'm not sure. At a glance I like it, but then I think about other 
things that we may want to do in the future, e.g. constraints.

constraints?

e.g. specify that an integer param must be positive.

honestly, Gregg, if you measure the times you'd need a default value 
wrt any other func enhancement ... I am sure default values are far 
ahead.

just about every other func I use would have default values in them. 
 hell in python I don't even recall one function which didn't have 
default values... they are just so usefull.

True, today, but I also know that I have a *lot* of code that validates 
parameter values, and if that could be done declaratively...

one thing that is better in the [] version is that it fits with the 
current model of annotating the value in front of it

It's the REBOL problem of being able to do anything, and we need 
to think about how we really want to write functions IF (and that's 
a big IF) it's something that affects R3.

but the block also get ambiguous, as gregg pointed out, trying to 
set a default value of datatype gets pretty unobvious... and even 
quirky.

i.e. if we come up with a really ambitious func spec dialect, should 
we propose it now, for R4, or never (and just mezz it in for those 
who want to use it)?

hum... are default values part of  ambitious?

I think they're the first step on that slippery slope. :-)

Not too ambitious in themselves though, and *so* useful that I think 
it's worth pushing for it.

hehe, IMHO NOT having default values is a current REBOL shortcomming. 
 ;-)

a lot of code would get a few lines trimmed

I agree 100%.

especially if the values are reset at each function call.

Trimmed, and become much cleaner in intent.

cleaner = clearer. doh! :-)

yes, especially if the set-word approach is used... just a casual 
glance at the spec indicates something is being set.  otherwise, 
one needs to know it.

the datatype block is obvious because they are datatypes within the 
block.

Gotta run. Great chat guys!

square: func [x [decimal! (x > 0) complex!]][x * x]


will be very difficult to get it right if other things should be 
allowed later :-/

should have been sqrt :-)