On Wednesday, June 20, 2012 19:59:08 ixid wrote:
> I see that this is not going to happen for D2 but as a debate for a future D3 (and please just ignore my post if you find this in some way exasperating, I am interested but do not mean to cause friction):
> 
> Just as a question about the existing syntax as you listed
> 
> combinations to learn as a negative:
> > auto name = initializer;
> > const name = initializer;
> > immutable name = initializer;
> > shared name = initializer;
> > enum name = initializer;
> 
> After the first aren't these all just short hand for "const auto name = init" etc with the given keyword? If your argument is that additional cases are bad then this is a case for what appears to be syntactic reasons. It feels as if initialization should be more explicit than keyword varname. As a beginner I certainly found that odder than :=.
> 
> Syntax confusion with other languages is not a strong argument, well at least as the confusion is with unrelated languages. Fortran uses /= for not equal, Matlab uses ~=, while that is D's append to self.
> 
> Terse elegance is important in making languages quick to take in and work with, it's not an argument of new function but that is not the only reason to include features, convenience is a good reason when there is no ambiguity.

A language can certainly use whatever syntax it wants to, but if it uses a syntax that no other language uses or reuses a particular piece of syntax for something completely different, it comes at a cost in terms learning and knowing the language. It's often the case that someone will argue that something should be added simply because another language does something in a particular way, and use that as an argument. Arguing that something shouldn't be added because no other language does it that way is basically the same argument but in reverse.

D _has_ done some if its own stuff already (e.g. ~ and ~= for concatenation and appending), so the fact that no other language did something a particular way is not necessarily a barrier to having D do it that way, but there needs to be a good reason for it, and at this stage in the game, we're not gonig to make changes like that without a _really_ good reason.

Regardless, := just doesn't match what D currently does. And given that other languages have

auto name = initializer;

or something very similar (e.g. IIRC C# uses var instead of auto; C++11 however uses the exact same syntax as D), auto is very much in line with what other languages are doing (regardless of whether any other language uses := in a manner similar to what you're proposing). So, whether auto or := is more immediately obvious is completely a matter of what your personal experience is. It's going to vary from programmer to programmer. Personally, if a language uses :=, I would have expected it to be used for what D uses = for rather than auto.

Obviously, you're going to have to learn new stuff in learning any language, and we're unlikely to change anything at this point simply because someone thinks that another language's syntax is better and that D should use it. Even if the other syntax _were_ better, it's too late in the game to change it now without a really compelling reason. And adding a second way to do things on top of the first is just going to make it so that there are _more_ things for a D newbie to learn, and D is already far from being small.

Who knows what'll happen with D3. It's years off yet, if it will even ever happen at all. What we do with it will be discussed then, so it's pretty much irrelevant now. However, I'd be very surprised if we made a minor syntactic change like this for it, since it would just make D2 code harder to port to D3 without providing any real benefit (the only benefit is whatever aesthetic benefit a particular programmer might see in using := over auto).

You're free to propose and discuss possible changes for D3, but there's very little in terms of language changes that are going to happen to D2 at this point (especially syntactically), and personally, I think that it's a waste of time to discuss possible changes for D3 given that it's likely 10+ years off and that what we decide to do with it is going to be highly dependent on the lessons learned while using D2 over that time period.

- Jonathan M Davis

On Wednesday, 20 June 2012 at 14:36:48 UTC, ixid wrote:
> Is there any reason not to add this so you can use foo := bar as a shorthand for auto foo = bar?

I would be against this change. There isn't much to say agaist it especially since => was fairly recently added (though has more benefit than I see here). The word auto is not hard to type for a Dvorak user, it kind of just roles off (auto). Declarations would then need to be identified by starting with auto or variable :=.

And on that similar point, Vim fails to go to declarations already. While I don't anticipate trying to fix this anytime soon, the new form would likely make this yet another thing to go wrong.

Somewhere you made a comment about

const auto ...;

No, it is

const int ...;

You can't include auto if you are using const/immutable... but you can include the actual type.

On Wednesday, 20 June 2012 at 17:19:08 UTC, Jonathan M Davis wrote:
> Not to mention, there are some programming languages (e.g. Pascal) which use := for normal assignment, so it would be confusing for anyone familiar with those languages.

 AutoIt or AutoHotKeys is one, where = and := do two very different things (and confusing for a first time user).

 As for the topic of discussion, I think := should not be used as it has very few useful cases, but also it's making two incompatible operators compatible.

Consider:

test:=5;
for(/*something*/) {
/*something*/

 b++;
 if (b > 10)
    goto test;
}

--

 In the example above, test:=5 should have been test: b=5. It may potentially hide even worse bugs, where currently := is illegal and easy to spot by a compiler error.

 Besides, isn't 'auto' short enough? as mentioned you may save 2 characters. Not worth it. Be worse if you use it in two places and it's now trying to declare the same variable twice and there's nothing there suggesting it's being declared. One character is easy to miss or forget.

 The worst bugs I've gone against are usually the simplest, easiest and most subtle.

On Wednesday, 20 June 2012 at 17:59:08 UTC, ixid wrote:
>
> Just as a question about the existing syntax as you listed combinations to learn as a negative:
>
>> auto name = initializer;
>> const name = initializer;
>> immutable name = initializer;
>> shared name = initializer;
>> enum name = initializer;
>
> After the first aren't these all just short hand for "const auto name = init" etc with the given keyword?

No. Many don't realise this, but "auto" doesn't  actually stand for "automatic type inference". It is a storage class, like static, extern, etc., and it means that the variable stops existing at the end of the scope. It is, however, the default storage class, which is why it is useful when all you want is type inference. Even C has auto.

Lars

On Thursday, 21 June 2012 at 05:54:32 UTC, Lars T. Kyllingstad wrote:
> No. Many don't realize this, but "auto" doesn't  actually stand for "automatic type inference". It is a storage class, like static, extern, etc., and it means that the variable stops existing at the end of the scope. It is, however, the default storage class, which is why it is useful when all you want is type inference. Even C has auto.

 Interesting. But doesn't auto for C default to int?

On Thursday, 21 June 2012 at 05:54:32 UTC, Lars T. Kyllingstad wrote:
> No. Many don't realise this, but "auto" doesn't  actually stand for "automatic type inference". It is a storage class
>
> Lars


auto int a = 5;
// Error: variable a storage class 'auto' has no effect if type is not inferred, did you mean 'scope'?



I don't understand what kind of a "storage class" this is.

You would be correct in C, but is it really a 'storage class' in D?

(Sure it's called that, but it doesn't seem to behave like one...)

"Lars T. Kyllingstad" , dans le message (digitalmars.D:170370), a
>>> auto name = initializer;
>>> const name = initializer;
>>> immutable name = initializer;
>>> shared name = initializer;
>>> enum name = initializer;
>>
>> After the first aren't these all just short hand for "const auto name = init" etc with the given keyword?
> 
> No. Many don't realise this, but "auto" doesn't  actually stand for "automatic type inference". It is a storage class, like static, extern, etc., and it means that the variable stops existing at the end of the scope. It is, however, the default storage class, which is why it is useful when all you want is type inference. Even C has auto.

auto is called a storage class, but where did you read that auto would make the variable stop existing at the end of the scope ?

int delegate(int) add(int i, int j)
{
  auto k = i+j;
  return a => a+k;
}

Are you sure k will stop existing at the end of the scope ? I have no compiler at hand to check this, but I would be very surprised.

Object Create()
{
  auto k = new Object();
  return k;
}

Same question.

-- 
Christophe

On Thursday, June 21, 2012 08:04:35 Christophe Travert wrote:
> "Lars T. Kyllingstad" , dans le message (digitalmars.D:170370), a
> 
> >>> auto name = initializer;
> >>> const name = initializer;
> >>> immutable name = initializer;
> >>> shared name = initializer;
> >>> enum name = initializer;
> >> 
> >> After the first aren't these all just short hand for "const auto name = init" etc with the given keyword?
> > 
> > No. Many don't realise this, but "auto" doesn't  actually stand for "automatic type inference". It is a storage class, like static, extern, etc., and it means that the variable stops existing at the end of the scope. It is, however, the default storage class, which is why it is useful when all you want is type inference. Even C has auto.
> 
> auto is called a storage class, but where did you read that auto would make the variable stop existing at the end of the scope ?

Yeah. I'm pretty darn sure that he's wrong on that. All auto is type inference. auto has no effect on the lifetime of a variable. _All_ variables cease to exist when they exit scope. And reference and pointer types continue to exist on the heap (it's just that the pointer or reference is gone) without being destroyed or freed or whatnot. So, I don't know where Lars got the idea that auto was anything other than type inference. Sure, it might be termed a storage class, but that term seems to be pretty much meaningless in D.

- Jonathan M Davis

I think he is speaking about "auto" keyword in c++.
In c++ auto mean that. (local lifetime)

On Thursday, 21 June 2012 at 08:12:58 UTC, Jonathan M Davis wrote:
> On Thursday, June 21, 2012 08:04:35 Christophe Travert wrote:
>> "Lars T. Kyllingstad" , dans le message (digitalmars.D:170370), a
>> 
>> >>> auto name = initializer;
>> >>> const name = initializer;
>> >>> immutable name = initializer;
>> >>> shared name = initializer;
>> >>> enum name = initializer;
>> >> 
>> >> After the first aren't these all just short hand for "const
>> >> auto name = init" etc with the given keyword?
>> > 
>> > No. Many don't realise this, but "auto" doesn't  actually stand
>> > for "automatic type inference". It is a storage class, like
>> > static, extern, etc., and it means that the variable stops
>> > existing at the end of the scope. It is, however, the default
>> > storage class, which is why it is useful when all you want is
>> > type inference. Even C has auto.
>> 
>> auto is called a storage class, but where did you read that auto would
>> make the variable stop existing at the end of the scope ?
>
> Yeah. I'm pretty darn sure that he's wrong on that. All auto is type
> inference. auto has no effect on the lifetime of a variable. _All_ variables
> cease to exist when they exit scope. And reference and pointer types continue
> to exist on the heap (it's just that the pointer or reference is gone) without
> being destroyed or freed or whatnot. So, I don't know where Lars got the idea
> that auto was anything other than type inference. Sure, it might be termed a
> storage class, but that term seems to be pretty much meaningless in D.
>
> - Jonathan M Davis

On Thursday, 21 June 2012 at 08:12:58 UTC, Jonathan M Davis wrote:
> On Thursday, June 21, 2012 08:04:35 Christophe Travert wrote:
>> "Lars T. Kyllingstad" , dans le message (digitalmars.D:170370), a
>> 
>> >>> auto name = initializer;
>> >>> const name = initializer;
>> >>> immutable name = initializer;
>> >>> shared name = initializer;
>> >>> enum name = initializer;
>> >> 
>> >> After the first aren't these all just short hand for "const
>> >> auto name = init" etc with the given keyword?
>> > 
>> > No. Many don't realise this, but "auto" doesn't  actually stand
>> > for "automatic type inference". It is a storage class, like
>> > static, extern, etc., and it means that the variable stops
>> > existing at the end of the scope. It is, however, the default
>> > storage class, which is why it is useful when all you want is
>> > type inference. Even C has auto.
>> 
>> auto is called a storage class, but where did you read that auto would
>> make the variable stop existing at the end of the scope ?
>
> Yeah. I'm pretty darn sure that he's wrong on that. All auto is type
> inference. auto has no effect on the lifetime of a variable.

I admit that "stop existing at the end of the scope" was perhaps imprecise to the point of being wrong.  Here's Microsoft's description of the auto storage class in C:

  The auto storage-class specifier declares an
  automatic variable, a variable with a local
  lifetime. An auto variable is visible only in
  the block in which it is declared.

All variables except those marked 'register', 'static' or 'extern' are 'auto' in C.

That said, I was still wrong. :)  I just tried it now, and apparently you can write pointless stuff like "auto extern int foo;" and DMD will compile it just fine.  (And, unless that is a bug, it means D has redefined 'auto' to mean absolutely nothing, except to be a marker saying "this is a declaration", allowing one to omit both storage class and type.)

auto should probably be removed from the list of storage classes in the D spec, then.

> _All_ variables
> cease to exist when they exit scope.

Not static ones, but again maybe you took "stop existing" to refer to the name rather than the storage.

-Lars