Why is there no or or and ?

[F i L]

On Friday, 17 February 2012 at 07:21:32 UTC, Nick Sabalausky 
wrote:
> "F i L" <witte2008 at gmail.com> wrote in message 
> news:simejelbyihexcsbkoyl at forum.dlang.org...
>>I would use them over '||' and '&&' for the reasons bearophile 
>>gave. Highlighted as keywords, they're easily set appart, 
>>easier to type, and more distinguished... then again if I had 
>>my way I'd remove the '('/')' brackets, ending marks, and auto 
>>keyword; switched the definition name-type placement and change 
>>if/else/return/contract syntax...
>>
>>     foo( a, b: float ): int
>
> In other languages, I can live with JS-style "var:Type" but 
> I've never really liked it. Just seems totally backwards to me:
>
> 1. When I declare a variable, I normally know the type I want 
> before I know what to name it, so just typing it in is 
> backwards.

This usually happens to me if I've been coding a lot of C# or 
Javascript then switch to the other; but i usually get accustom 
to the change pretty quick. However, I do agree some people feel 
more natural thinking in one way, so for readability, identifiers 
should be listed first, while the IDE should allow either to be 
typed first; rearranging the syntax as you type intelligently. 
Possibly the syntax should accommodate both, though I'm not sure 
of any conflicts that way.


> 2. With function definitions, why is the return type so 
> rediculously far away from the function name? Should be 
> "foo:int( a, b: float )". Besides, when you call the func and 
> assign the return value to a variable, the return value is 
> going to the left, not the right. In C-style, return 
> values/types move "left". In JS-style, it's all willy-nilly.

I was thinking this would conflict with template derivitives, but 
on second thought, I think it would work better the way you say.

     Foo(T): struct { ... }
     Bar(U): Foo!U { ... }

Thanks!


> 3. Makes it harder to distinguish declarations from assignments 
> at a glance. You have to look in the middle of the statement to 
> see what the heck it is. With C-style you only have to look at 
> the beginning (which are conveniently all lined up): Starts 
> with a variable? Assignment. Starts with a type or attribute? 
> Declaration. Starts with colored text? *Definitely* 
> declaration. Don't see why languages keep trying to marginalize 
> the idea of declarations.

Fair point. Though I personally don't find it difficult at all 
and think it lines up nicely with sequencial property sets:

     bar: = new Bar!int
     bar.name = "bar"
     bar.value = 10


> 4. Initializers are just downright goofy:
>
> a:int = 5;
>
> Looks like it's assigning 5 to "int" instead of to "a", which 
> is completely nonsensical.

I think it makes sense. Just takes some getting use to if you're 
use to writing C-style code.