[rust-dev] Function definition syntax

On 13-07-29 04:29 PM, Wojciech Miłkowski wrote: > Hi, > > I'm observing rust development for some time, and I must say it slowly > encourages me to use it. Especially the progress from Perl-like syntax > to more sane and quiet form is enjoyable. > That said I wonder why the function definition has form: > fn name(var: type, ...) -> return_type {...} > instead of more unified: > fn name(var: type, ...): return_type {...} Sigh. Speaking of Perl! "Larry's First Law of Language Redesign: Everyone wants the colon." We get this question every now and then, which is perhaps an indication that we're attracting more people from Scala-land than I expected. I can't imagine it's converts from Pascal! Let's tally up some function tycons from the world of languages: In the "->" column: Normal Mathematics[1] Simply Typed Lambda Calculus[2] C++11 alternative function syntax[3] Typed Racket[4] Typed Python[5] The term-rewrite languages (OBJ, Maude, Q, Pure) The ISWIM languages (Miranda, Hope, Clean, Haskell, ML, Ocaml, F#) In the ":" column: Scala One older Pike language (Limbo) The Wirth languages (Pascal, Modula-3, Oberon) Eiffel and Sather Our extremely worthy competitors Clay and Nimrod In the "some form of juxtaposition" column: C and C++ C#, Java D Cyclone Alef and Go If the argument's about consistency, I think the consistent thing to do is to keep ":" as a separator between bindings and types. My eyes get a little fuzzy guessing the associativity of "let x : fn(T) : U;" in a way that they do not when reading "let x : fn(T) -> U;". But I suppose reasonable people could disagre, or phrase the consistency requirement differently. My math professors would cry. Do people feel strongly? I think we've many better things to spend time on, and I'm not certain it won't raise an ambiguity. It'd also break every single patch, branch and package in progress (and personally, my heart is with the ISWIMs). -Graydon [1] http://en.wikipedia.org/wiki/Function_%28mathematics%29#Notation [2] http://en.wikipedia.org/wiki/Simply_typed_lambda_calculus#Syntax [3] https://en.wikipedia.org/wiki/C%2B%2B11#Alternative_function_syntax [4] http://docs.racket-lang.org/ts-guide/types.html#%28part._.Function_.Types%29 [5] http://www.python.org/dev/peps/pep-3107/