"Charles" <noone@nowhere.com> wrote in message news:devlr0$8gp$1@digitaldaemon.com...
>I love it.  However ,
>
>>for (i:=0; i<10; i++) {...}
>
> how does the compiler know to make i an int , as opposed to a uint / real
> /
> other compatible type?  A cast there would make it worse then explictly
> defining the type IMO.

The type of 0 is int. To get uint write 0U or 0u. To get real write 0.0L or 0.0l (since a lower-case l looks like a 1, however, I recommend using L).

I agree writing
 short x = 0;
is better than
 x := cast(short)0;
No-one is saying good-ol' declarations will go away so obviously the
preferred way is to use a standard declaration rather than casting and using
implicit declarations.

Ben Hinkle wrote in news:devhba$4bh$1@digitaldaemon.com

[...]
> If you want more motivation see previous D posts requesting tings like this
[...]

I already have posted some of these myself, but nobody seems to catch the sarcasm. The comunity starts to nit pick on syntactic saccharin by declaring it as syntactic sugar while weighty points of D remain undefined or ambiguous and nobody cares.

In the forum attached to the article you cited, Walter has given the astonishing statement, that D goes into the direction the comunity wants D to go. So stop these talks on saccharin: move D!


[...]
>> Do you fear, that someone makes a typo and therefore
>>  indx= g( h( 1));
>> goes undetected?
> yes
[...]
>> And if you want to prevent typos at all, what other schemes do you propose to secure that the programmer knows what she/he types?
> huh?

You fear, that a typo like `indx= g( h( 1));' goes undetected if one wants to write `index= g( h( 1));' and index is a declared variable.

Therefore if `index' is not a name of a declared variable you want the type of `index' to be inferred from the acompanying assignment by changing the `=' to a `:='.

You want this redundancy. But in the RHS there might be a typo also `index:= g( g( 1));' contains also only one typo and might change the type of `index' to something completely different which may go undetected, because the function(s) receiving `index' as a parameter has(ve) overload(s) for this type.

If the variable declared this way is public it may very well have severe consequences in a large scale project.

So, please explain, why you need redundancy in order to have irredundancy.

-manfred

> You fear, that a typo like `indx= g( h( 1));' goes undetected if
> one wants to write `index= g( h( 1));' and index is a declared
> variable.
>
> Therefore if `index' is not a name of a declared variable you want the type of `index' to be inferred from the acompanying assignment by changing the `=' to a `:='.
>
> You want this redundancy. But in the RHS there might be a typo also
> `index:= g( g( 1));' contains also only one typo and might change
> the type of `index' to something completely different which may go
> undetected, because the function(s) receiving `index' as a
> parameter has(ve) overload(s) for this type.

I agree that is a risk when the user relies on := instead of explicit declarations.

> If the variable declared this way is public it may very well have severe consequences in a large scale project.

I don't believe the risk is severe. I've been coding in MATLAB for years and
frankly typos are a small source of bugs. In code of significant complexity
the user can be as strict as they want by only using explicit declarations
and stict to implicit declarations for when they feel comfortable. In any
case if the user had an explicit declaration like
  int index = g(g(1))
and g(x) computed something like 2*x while h(x) computed 3*x then obviously
the code is still hosed and contains a bug. With or without implicit
declarations there is no bullet-proof way to prevent people from typing the
wrong symbol.

> So, please explain, why you need redundancy in order to have irredundancy.
>
> -manfred

> Do you fear, that someone makes a typo and therefore
>  indx= g( h( 1));
> goes undetected?

I should add to my previous posts that the main reason for not changing = to implicitly declare is to allow coders to "opt-in" to the new semantics. People porting C/C++/Java code don't have to worry about suddenly all their = operators implicitly declaring stuff. Users can safely ignore := if they want to and always write "traditional" C with explicit declarations.

In article <dessc7$v3n$1@digitaldaemon.com>, Ben Hinkle says...
>
>I don't know if this has been proposed before but I was thinking how nice it is to work in MATLAB (where you don't have to declare a variable's type) and the following operator came to mind
>  var := init;

Sorry for the delay. Having some trouble with Katrina. At any rate, I love it. This would come quite handy in a large number of situations. Moreover, it includes the benefits of ExpressionStatements, without the parsing ambiguities. You have my vote.

Cheers,
--AJG.






>is the same as
>  typeof(init) var = init;
>
>That means, for example, if ReallyLongClass is a class that
>
>  ReallyLongClass f = new ReallyLongClass;
>
>can be replaced with
>
>  f := new ReallyLongClass;
>
>It even will come in handy with lots of little variables like
>  for (i:=0; i<10; i++) {...}
>
>If := appears inside an expression (say, expr) in a statement (say, stmt) like
>  if ((p := strchar(q,'a')) != null) {
>     ... use p ...
>  }
>then the rewritten code is
>  { typeof(init) var; stmt' }
>where stmt' is stmt with := replaced with = in expr.
>
>Another example using if-else statement (from http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/27542)
> if ((line := ReadLine()) != null) {
>      printf("We got a line, Chief!");
>      line = EscapeLine(line);
>      DeployLine(line);
> } else {
>      printf("We are out of lines, Chief!");
>      line = "Emergency Line";
>      DeployLine(line);
> }
>is equivalent to
> {
>   char[] line;
>   if ((line = ReadLine()) != null) {
>      printf("We got a line, Chief!");
>      line = EscapeLine(line);
>      DeployLine(line);
>   } else {
>      printf("We are out of lines, Chief!");
>      line = "Emergency Line";
>      DeployLine(line);
>   }
> }
>
>An example that wouldn't work (from http://www.digitalmars.com/d/archives/digitalmars/D/20481.html)
>
>  do {
>    x := getchar();
>  } while (x != 'x');
>
>since x:=getchar(); is the deepest statement enclosing the := so the declaration wouldn't be visible to the while condition.
>
>This proposal avoids the parsing ambiguity that Stewart found with
>  if ((a*b = c) != 0) {...}
>since the a*b would continue to be parsed as it is today - as multiplication.
>
>
>A "real-life" example is a modified std.string.find from phobos. Notice that
>it only needs declarations where some unsigned size_t array lengths are
>assigned to ints.
>int find(char[] s, char[] sub)
>{
>  int sublength = sub.length;
>
>  if (sublength == 0)
>    return 0;
>
>  c := sub[0];
>  if (sublength == 1)
>  {
>      p := memchr(s, c, s.length);
>      if (p)
>         return p - &s[0];
>  }
>  else
>  {
>      int imax = s.length - sublength + 1;
>
>      // Remainder of sub[]
>      q := &sub[1];
>      sublength--;
>
>      for (i := 0; i < imax; i++)
>      {
>        p := memchr(&s[i], c, imax - i);
>        if (!p)
>          break;
>        i = p - &s[0];
>        if (memcmp(p + 1, q, sublength) == 0)
>          return i;
>      }
>  }
>  return -1;
>}
>
>
>

On Mon, 29 Aug 2005 20:16:54 +0000 (UTC), Manfred Nowak wrote:

> The comunity starts to nit pick on syntactic saccharin by declaring it as syntactic sugar while weighty points of D remain undefined or ambiguous and nobody cares.

I did note that 'standardized documentation' comes out at 38 of 41 wishlist items ;-)

  http://all-technology.com/eigenpolls/dwishlist/index.php

-- 
Derek Parnell
Melbourne, Australia
30/08/2005 10:23:01 AM

Derek Parnell wrote:

[...]
> I did note that 'standardized documentation' comes out at 38 of 41 wishlist items ;-)
> 
>   http://all-technology.com/eigenpolls/dwishlist/index.php

Oh wow. Had my first look into that list and I must say.

-manfred

Ben Hinkle wrote in news:devrpp$e1m$1@digitaldaemon.com

[...]
> With
> or without implicit declarations there is no bullet-proof way to
> prevent people from typing the wrong symbol.
> 
>> So, please explain, why you need redundancy in order to have irredundancy.

Therefore the request keeps valid.

-manfred

Ben Hinkle wrote:

[...]
> People porting C/C++/Java code don't have
> to worry about suddenly all their = operators implicitly
> declaring stuff.
[...]

Running code rarely has assignments to undefined names. Therefore porting running code causes no worries. Paranoids can be served with a pragma switching implicit declarations off.

-manfred

In article <det4pk$16si$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:det1o2$1403$1@digitaldaemon.com...
>> Seems like a handy syntactic sugar, but I'm of the opinion that too much
>> sugar is a kind of bloat; yes, it's convenient, but it adds unnecessary
>> complication to the syntax.
>> Plus, I hated that := operator from pacal.
>>
>> However, maybe we could use something more consistent with the current design, like:
>>
>> #typeof var = init;
>>
>> Where typeof is not followed by an opening parenthesis, so a default
>> (init) is assumed.
>> This is similar to the behaviour of 'extern' for example, where if it's
>> not followed by a parenthesis, a default (D) is assumed. Same for align.
>>
>> However,
>> #typeof var = init;
>> maybe misleading, as it /can/ read: "var is a variable whose tyoe is the
>> same type as var", so maybe another keyword should be introduced:
>> #auto_type var = init;
>>
>> or just
>> #type var = init;
>
>There's a proposed C++ extension that uses 'auto' (or maybe 'decl' I can't
>remember). I prefer the operator because
>1) it's less typing (one of the goals of the idea is to cut down verbosity)
>2) it is used to declare variables in expressions, too.

There could be some advantages to 'auto' too. It could be used to make simple templates:

auto f(auto x) { return x+1;}

This would be most useful when defining function literals. Like:

LongTypeName[] all = whatever(...);
auto good = filter(all, function auto(auto x) { return x.isGood(); });

One alternative is to add type declarations implicitly when missing in function literals... Just remove the auto above:

filter(all, function(x) { return x.isGood(); });

This is not incompatible with your := suggestion (which I really like!)

/Oskar