Exactly.  At this point, there is nothing fundamentally changed regarding
Ruby.  Just like "attr_reader :a" is only a shortcut for

    def a
        return @a
    end

the new syntax "def func (Float a, String b, Fixnum c)" is only a
shortcut for

    def func (a, b, c)
        raise "type error" unless a.kind_of Float
        raise "type error" unless b.kind_of String
        raise "type error" unless c.kind_of Fixnum

I think, at least with this new syntax Ruby will become more friendly to
people with strongly-typed language background, while it may save some
typing for the Ruby programmers themselves, if indeed we need to check the
class of an input.  (Hey, with very simple thing like this I guess I can
just put it in my own personal translator; this is even easier as class
name should start with an uppercase while the variable with a lowercase.)

Now, if we want to go further by also checking later when a, b, or c gets
new assignments, that is a different story.  The Ruby parser needs to be
modified (but not the Ruby fundamental object model nor its internals at
all).

Regarding sugar, I think Matz has said that Ruby is not a minimalist
language; we have both "if" and "unless".  Then of course, the sugar-level
propensity of each person is different :)

Regards,

Bill
===========================================================================
Mauricio Fern?ndez <batsman.geo / yahoo.com> wrote:
> You have gained no type-safety whatsoever.
> This isn't static typing but a better way to see if your code is doing
> what you think, as the test is not performed at compile-time.

>> Well, Ruby already have concepts of "shortcuts" such as attr_reader and
>> attr_accessor.  So at least initially "static type" can simply be
>> interpreted as a shortcut as in the above code.

> I believe this shortcut can easily be implemented in Ruby as it is right
> now... your notation is just more syntactic sugar, IMHO. But then again,
> maybe I'm seeing sugar everywhere :-)