"Walter Bright" <newshound@digitalmars.com> wrote in message news:du187d$14bk$2@digitaldaemon.com...
>
> "Lionello Lunesu" <lio@remove.lunesu.com> wrote in message news:du10fg$q5p$1@digitaldaemon.com...
>> Do you mean the two seemingly different "auto"s are not ambigious?
>
> That's right.
>
>>> 'var' would be a digression into pascalishness (ugh <g>).
>> I'm just glad you didn't use this argument against array slicing ; )
>
> Pascal doesn't do array slicing.

Probably GPC specific then: http://www.gnu-pascal.de/gpc/String-Slice-Access.html

Although the notation array[x..y] was already used in 'normal' Pascal when declaring arrays.

L.

Is it more concise to the maintainer if they are unfamiliar with the given type?

(in case of 'if (m; mystery())' maintainer will have to discover what mystery() returns instead of knowing it returns given 'type' right off the bat.

Might this negate any time saved in typing?

Walter Bright wrote:
> "clayasaurus" <clayasaurus@gmail.com> wrote in message news:dtvmkf$2e1a$1@digitaldaemon.com...
>> I'll vote against it because I don't understand the value of
>>
>> if (m; search("abcdef", "BcdasdfD"))
>>
>> over
>>
>> if (Regexp m = search("abcdef", "BcdasdfD") ) .
>>
>> Maybe someone can enlighten me?
> 
> 1) m is implicitly typed
> 2) looks like the foreach
> 3) more concise 
> 
> 

Walter Bright wrote:
> "Georg Wrede" <georg@nospam.org> wrote in message news:4401ECE3.4030207@nospam.org...
> 
>>Now consider:
>>
>>        if (Regexp m = std.regexp.search("abcdef", "b(c)d"))
>>        {
>>            writefln("[%s]", m.pre);      // prints [a]
>>            writefln("[%s]", m.post);     // prints [ef]
>>            writefln("[%s]", m.match(0)); // prints [bcd]
>>            writefln("[%s]", m.match(1)); // prints [c]
>>            writefln("[%s]", m.match(2)); // prints []
>>        }
>>
>> Flaunting this around (to both the original programmers, and also
>> to virgin victims), gave the same, _immediate_ comment from
>> everybody: "Ah, that's neat!"
> 
> The idea behind m; was to be like foreach. What do the "victims" <g>
> think of:
> 
> if (auto m = std.regexp.search("abcdef", "b(c)d"))

Another round, and everyone had no problem immediately understanding the code. And the word "auto" was universally assumed as in "autotype".

Found one "still virgin" non-D programmer, and even he immediately assumed the correct functionality, and took for granted that "auto" meant that the compiler figures out the actual type.

clayasaurus wrote:
> Is it more concise to the maintainer if they are unfamiliar with the given type?
> 
> (in case of 'if (m; mystery())' maintainer will have to discover what
> mystery() returns instead of knowing it returns given 'type' right off
> the bat.
> 
> Might this negate any time saved in typing?
> 

That's very true. This kind of code isn't very self documenting. You have to search through the API (can take a lot of time) or just remember it somehow. In a huge class hierarchy this will be a major setback, what do you think?

Walter Bright wrote:
> "Charles" <noone@nowhere.com> wrote in message news:du002j$2pcm$1@digitaldaemon.com...
>> I think its short for 'auto' deduction ?
>>
>> 'var' gets my vote
> 
> 'auto' goes way back to C and means "allocate on the stack". This also implicitly means "destruct at end of scope." In order for type inference to work, there has to be a keyword in front of the declaration to let the parser know it's a declaration rather than an assignment. Thus, 'auto' now means "allocate on the stack" and if the type is missing it also means "infer the type."

Hold on.  Certainly you aren't suggesting that "auto myClass = new MyClass()" constructs an object that will be destroyed on scope exit? And if so, how do I auto-type objects without the RAII functionality?


Sean

Bruno Medeiros wrote:
> Walter Bright wrote:
>> "Charles" <noone@nowhere.com> wrote in message news:du002j$2pcm$1@digitaldaemon.com...
>>> I think its short for 'auto' deduction ?
>>>
>>> 'var' gets my vote
>>
>> 'auto' goes way back to C and means "allocate on the stack". This also implicitly means "destruct at end of scope." In order for type inference to work, there has to be a keyword in front of the declaration to let the parser know it's a declaration rather than an assignment. Thus, 'auto' now means "allocate on the stack" and if the type is missing it also means "infer the type." Types can be inferred with other storage classes:
>>
>>     static x = 3;        // x is int
>>
>> This follows the 'auto' proposal for C++ as far as I know.
>>
> Now this is something I've been meaning to comment on but haven't yet. This is damn AWFUL. No autotype declaration should work without the the autotype keyword! And I don't care if if deviates from the C++ or not, it's just plain bad. *angry face*
> 
>> 'var' would be a digression into pascalishness (ugh <g>).
> It wouldn't be, because they do different things. And even if it were, what would be the problem?? What matters in a feature/design is how good it is, not if it is similar to other languages or not.

That's true. And many other "good" features like with-statements in D originate from Pascal. IMO the worst things in Pascal are variable declarations and too long keywords, otherwise it's damn illustrative and rational language.

-- 
Jari-Matti

"Derek Parnell" <derek@psych.ward> wrote in message news:op.s5ol8l1e6b8z09@ginger.vic.bigpond.net.au...
> I've forgotten: what's the syntax to automatically allocate on the static, a variable whose type is automatically type-cast? Is it ...
>
>    auto auto x = readtext(somefile);

automatically allocate on the static? I don't understand.

"Lionello Lunesu" <lio@remove.lunesu.com> wrote in message news:du1lnl$1ko0$1@digitaldaemon.com...
>
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:du187d$14bk$2@digitaldaemon.com...
>> Pascal doesn't do array slicing.
>
> Probably GPC specific then: http://www.gnu-pascal.de/gpc/String-Slice-Access.html

The article does say it is for "Extended" Pascal. That's the trouble with Pascal - it is unusable as defined. Every useful implementation found it necessary to add numerous extensions.

> Although the notation array[x..y] was already used in 'normal' Pascal when declaring arrays.

Yes, but that isn't array slicing, it's more of a way to set the index for the 'zeroth' element. This is not supported in D.

Pascalish nested functions, however, *are* in D <g>. That was the only Pascal characteristic I missed.

"Derek Parnell" <derek@psych.ward> wrote in message news:op.s5olyeuu6b8z09@ginger.vic.bigpond.net.au...
> Language Bigot! <G>

I plead guilty as charged.

> Seriously though ... who cares if its a C thingy! This is NOT C.

It is a C derived language, and is meant to be an upgrade path for C users. Hence, gratuitous incompatibility is not a good idea. To diverge a particular feature from C, one needs a better reason than just liking a different spelling.

> But you  already know that. Just because C does 'X' is it good enough to justify  keeping 'X'? You've already changed lots of other things to achieve a  better, consistent, language - so why stop at this wart.
>
> 'auto', as a word, is too ambiguous to because it is an adjective that can apply to many things. Ok, so C applys it to automatic stack allocation and so does D, but D also applies it to automatic type-casting too. Why do you want your language to be ridiculed for this wart when it is so easy to change it. If you are too frightened of it being a Pascal-looking language (and 'var' will not do that, BTW), then pick some other more meaningful word.

It isn't ambigous since it doesn't really imply type inference - all it does is enable the parser to disambiguate an expression from a declaration:

    a = 3;        // declaration of 'a' with implicit typing? Or assign to
'a'?
    auto a = 3;    // ahh, now I know it's a declaration
    static a = 3;    // that's a declaration with implicit typing as well

"Jari-Matti Mäkelä" <jmjmak@utu.fi.invalid> wrote in message news:du25uo$29f3$1@digitaldaemon.com...
> IMO the worst things in Pascal are variable
> declarations and too long keywords, otherwise it's damn illustrative and
> rational language.

Yet Pascal was buried by the arrival of C, despite having a long head start on the PC.