Jump to page: 1 2 3
Thread overview
Add := digraph to D
Jun 20, 2012
ixid
Jun 20, 2012
bearophile
Jun 20, 2012
ixid
Jun 20, 2012
bearophile
Jun 20, 2012
ixid
Jun 20, 2012
Bernard Helyer
Jun 20, 2012
ixid
Jun 20, 2012
Jonathan M Davis
Jun 20, 2012
Robert DaSilva
Jun 20, 2012
ixid
Jun 20, 2012
Jonathan M Davis
Jun 21, 2012
Era Scarecrow
Jun 21, 2012
Mehrdad
Jun 21, 2012
kenji hara
Jun 21, 2012
Christophe Travert
Jun 21, 2012
Jonathan M Davis
Jun 21, 2012
Andrea Fontana
Jun 21, 2012
Christophe Travert
Jun 21, 2012
Jonathan M Davis
Jun 22, 2012
Michel Colman
Jun 22, 2012
Michel Colman
Jun 22, 2012
Chris NS
Jun 21, 2012
Era Scarecrow
Jun 21, 2012
Jesse Phillips
Jun 22, 2012
F i L
June 20, 2012
Is there any reason not to add this so you can use foo := bar as a shorthand for auto foo = bar?
June 20, 2012
ixid:
> Is there any reason not to add this so you can use foo := bar as a shorthand for auto foo = bar?

Often I prefer to write:
const foo = bar;

D is more complex than Go...

Bye,
bearophile
June 20, 2012
How does that address my question? I didn't suggest the replacement or removal of syntax.


June 20, 2012
ixid:

> How does that address my question? I didn't suggest the replacement or removal of syntax.

I think your suggestion is not so useful because in many cases you don't want to use "auto". To justify the introduction of a new syntax it needs to cover many usage cases, or to do something that before was impossible/hard to, or bug prone, or very long to write, or very inelegant, etc.

With other people I have suggested to introduce a syntax like:

int[$] array = [1, 2, ....many more....];

This is useful because counting the items manually is boring and bug-prone.

Bye,
bearophile
June 20, 2012
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?

No. That is not how it works. You don't swan in and say "WHY NOT ADD THIS SYNTAX GUYZ?" _You_ have to justify it. Tell _us_ why it's useful.
June 20, 2012
Your array syntax suggestion is a good one. I think both make the syntax terser and more efficient which is a good justification for their use.


June 20, 2012
It is a terse way of assigning and initializing an automatically typed variable, helping meld what I understand one of D's aims to be that of the power of a C/C++ language with some of the syntactic elegance of languages like Python. In broad terms D and Go would seem to outline the general direction of C/C++ ideas, it would seem like a good idea to use the good ideas of each to move toward the optimum language.

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

Any proposed feature must have a solid use case and reason for being in the language. It needs to add real value. If you want a feature in the language, you need to show why it's truly worth having. This is especially true at this stage in the game. The language is supposed to be essentially stable at this point. We're ironing some stuff out still (primarily due to the compiler being behind the language definition), but we're not looking to make changes without good reason. And breaking changes _really_ need a good reason.

As for your particular suggestion, I don't see how it adds anything but complication. So, you write

foo := bar;

instead of

auto foo = bar

_All_ it is is a syntactic change. It saves you a few characters. It adds _no_ new functionality. It just adds one more thing that someone learning D has to learn and know. And it's not at all in line with how variable declarations normally work. What we currently have is very consistent. := doesn't fit in with that at all. For all variable declarations, we have

Type name = initializer;

In some cases, the type is inferred, but then type specifier is used in its place:

auto name = initializer;
const name = initializer;
immutable name = initializer;
shared name = initializer;
enum name = initializer;

If we implemnted your suggestion, then we'd have

name := initializer;
auto name = initializer;
const name = initializer;
immutable name = initializer;
shared name = initializer;
enum name = initializer;

It _only_ covers the auto case, and it doesn't fit in with the rest at all.

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. I'm not aware of any language which specifically uses := for auto, just for assignment (though if the language doesn't require variable declarations, then all assignments are essentially the same as declarations with auto). So, what you're proposing (AFAIK) would be a new usage for :=, even if it's similar to what other languages have done.

If you want something like this added, you need a compelling use case, and you don't seem to have one.

- Jonathan M Davis
June 20, 2012
On Wednesday, 20 June 2012 at 17:19:08 UTC, Jonathan M Davis wrote:
> On Wednesday, June 20, 2012 16:36:47 ixid wrote:
>> Is there any reason not to add this so you can use foo := bar as
>> a shorthand for auto foo = bar?
>
> Any proposed feature must have a solid use case and reason for being in the
> language. It needs to add real value. If you want a feature in the language,
> you need to show why it's truly worth having. This is especially true at this
> stage in the game. The language is supposed to be essentially stable at this
> point. We're ironing some stuff out still (primarily due to the compiler being
> behind the language definition), but we're not looking to make changes without
> good reason. And breaking changes _really_ need a good reason.
>
> As for your particular suggestion, I don't see how it adds anything but
> complication. So, you write
>
> foo := bar;
>
> instead of
>
> auto foo = bar
>
> _All_ it is is a syntactic change. It saves you a few characters. It adds _no_
> new functionality. It just adds one more thing that someone learning D has to
> learn and know. And it's not at all in line with how variable declarations
> normally work. What we currently have is very consistent. := doesn't fit in
> with that at all. For all variable declarations, we have
>
> Type name = initializer;
>
> In some cases, the type is inferred, but then type specifier is used in its
> place:
>
> auto name = initializer;
> const name = initializer;
> immutable name = initializer;
> shared name = initializer;
> enum name = initializer;
>
> If we implemnted your suggestion, then we'd have
>
> name := initializer;
> auto name = initializer;
> const name = initializer;
> immutable name = initializer;
> shared name = initializer;
> enum name = initializer;
>
> It _only_ covers the auto case, and it doesn't fit in with the rest at all.
>
> 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. I'm not aware of any language which specifically uses := for
> auto, just for assignment (though if the language doesn't require variable
> declarations, then all assignments are essentially the same as declarations
> with auto). So, what you're proposing (AFAIK) would be a new usage for :=,
> even if it's similar to what other languages have done.
>
> If you want something like this added, you need a compelling use case, and you
> don't seem to have one.
>
> - Jonathan M Davis

It's from Go, which has proper tuple syntax, it's main use is that it allows
you to declare a new var and reuse an old one. So it would be worth looking in to when we introduce a proper tuple syntax, but not now.

>Unlike regular variable declarations, a short variable declaration may
>redeclare variables provided they were originally declared in the same block
>with the same type, and at least one of the non-blank variables is new. As a
>consequence, redeclaration can only appear in a multi-variable short
>declaration. Redeclaration does not introduce a new variable; it just assigns
>a new value to the original.
June 20, 2012
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.
« First   ‹ Prev
1 2 3