View mode: basic / threaded / horizontal-split · Log in · Help
June 20, 2012
Re: Add := digraph to D
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
June 21, 2012
Re: Add := digraph to D
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.
June 21, 2012
Re: Add := digraph to D
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.
June 21, 2012
Re: Add := digraph to D
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
June 21, 2012
Re: Add := digraph to D
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?
June 21, 2012
Re: Add := digraph to D
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...)
June 21, 2012
Re: Add := digraph to D
"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
June 21, 2012
Re: Add := digraph to D
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
June 21, 2012
Re: Add := digraph to D
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
June 21, 2012
Re: Add := digraph to D
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
1 2 3
Top | Discussion index | About this forum | D home