I like it

How about for the Synchronize statement. To be fair I think something like that has also bean suggested with Foreach.


David Medlock wrote:
> 
> 
> I would say extend the with(...) construct to silently fail( and take an else clause ) if the object of the with statement is null.
> 
> with( Regexp m = std.regexp.search(...) )
> {
>   ...
> }
> else { ... }
> 
> Of course foreach is still preferred for multi returned values.
> 
> -DavidM
> 

Derek Parnell wrote:
> On Mon, 27 Feb 2006 17:14:28 -0500, Carlos Santander wrote:
> 
> 
>> Derek Parnell escribió:
>> 
>>> On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel
>>> <nils.hensel@web.de> wrote:
>>> 
>>> 
>>>> Lionello Lunesu schrieb:
>>>> 
>>>>> Talking of which: when is that "auto" ambiguity going to be
>>>>> resolved? (I still prefer "var" to "auto"
>>>> 
>>>> This would get my vote as well. "var" is far more intuitive and
>>>> it would be similar to DScript. I don't think there's an
>>>> obvious connection between "auto" and the data type of a
>>>> variable.
>>>> 
>>> 
>>> Thanks! There has been something bugging me about this since it
>>> appeared and that is it. True its an 'auto' but an auto what?
>>> Auto scope? Auto Type? Auto mobile? Auto initialization? Simply,
>>> 'auto' is way too ambiguous. At least 'var' is more focused.
>>> 
>>> --Derek Parnell Melbourne, Australia
>> 
>> I prefer auto for auto typing rather than for auto destruction.
>> Preferences...
> 
> 
> But that's my point ... 'auto' by itself is ambiguous and for a
> first-timer to understand it depends somewhat on one's preconceptions
> and preferences.

I agree.

auto for types is barely bearable. But something better should be invented. Personally I'd even settle for "var", in the worst case.

auto for RAII is not even barely bearable. We could even use "raii" rather than "auto". At least it wouldn't be ambiguous or opaque.

Derek Parnell escribió:
> On Mon, 27 Feb 2006 17:14:28 -0500, Carlos Santander wrote:
> 
>> I prefer auto for auto typing rather than for auto destruction. Preferences...
> 
> But that's my point ... 'auto' by itself is ambiguous and for a first-timer
> to understand it depends somewhat on one's preconceptions and preferences.
> 

You're right, but that's unavoidable. Someone waking up from 15 years ago, having only programmed in assembler, would have a hard time understanding "int" is not for "interrupt". I know that's extreme, but it's just to make my point. I think we all agree "auto" shouldn't be used for both cases. Walter just should pick one and use another syntax for the other. All we can do regarding that is give our input. In my case, I don't think I've ever had a variable/function/class/module named "auto", but I've had many variables "var".

I think I've only stated the obvious, but I just felt like I had to say it.

-- 
Carlos Santander Bernal

David Medlock wrote:
> Georg Wrede wrote:
> 
>> Better 'fess up front: the intent of this post is to once and for all murder, pulverize and extradite the new if construct.
>>
>> Consider:
>>
>>         if (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 []
>>         }
>>
>> Flauting this around has shown that experienced programmers have a hard time figuring out what is going on here.
>>

> 
> I would say extend the with(...) construct to silently fail( and take an else clause ) if the object of the with statement is null.

if (m; std.regexp.search("abcdef", "b(c)d"))
{
   writefln("Yippee!");
}
else
{
   writefln("Bad-ee.");
}

works already.

(Replace "abcdef" with "abXdef" to see.)

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4403B499.2060300@nospam.org...
> Derek Parnell wrote:
>> On Mon, 27 Feb 2006 17:14:28 -0500, Carlos Santander wrote:
>>
>>
>>> Derek Parnell escribió:
>>>
>>>> On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel <nils.hensel@web.de> wrote:
>>>>
>>>>
>>>>> Lionello Lunesu schrieb:
>>>>>
>>>>>> Talking of which: when is that "auto" ambiguity going to be resolved? (I still prefer "var" to "auto"
>>>>>
>>>>> This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable.
>>>>>
>>>>
>>>> Thanks! There has been something bugging me about this since it appeared and that is it. True its an 'auto' but an auto what? Auto scope? Auto Type? Auto mobile? Auto initialization? Simply, 'auto' is way too ambiguous. At least 'var' is more focused.
>>>>
>>>> --Derek Parnell Melbourne, Australia
>>>
>>> I prefer auto for auto typing rather than for auto destruction. Preferences...
>>
>>
>> But that's my point ... 'auto' by itself is ambiguous and for a first-timer to understand it depends somewhat on one's preconceptions and preferences.
>
> I agree.
>
> auto for types is barely bearable. But something better should be invented. Personally I'd even settle for "var", in the worst case.
>
> auto for RAII is not even barely bearable. We could even use "raii" rather than "auto". At least it wouldn't be ambiguous or opaque.
I second that; it would certainly make more sense.

"Ameer Armaly" <ameer_armaly@hotmail.com> wrote in message news:du0dh5$5v6$1@digitaldaemon.com...
>
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4403B499.2060300@nospam.org...
>> Derek Parnell wrote:
>>> On Mon, 27 Feb 2006 17:14:28 -0500, Carlos Santander wrote:
>>>
>>>
>>>> Derek Parnell escribió:
>>>>
>>>>> On Mon, 27 Feb 2006 22:25:37 +1100, Nils Hensel <nils.hensel@web.de> wrote:
>>>>>
>>>>>
>>>>>> Lionello Lunesu schrieb:
>>>>>>
>>>>>>> Talking of which: when is that "auto" ambiguity going to be resolved? (I still prefer "var" to "auto"
>>>>>>
>>>>>> This would get my vote as well. "var" is far more intuitive and it would be similar to DScript. I don't think there's an obvious connection between "auto" and the data type of a variable.
>>>>>>
>>>>>
>>>>> Thanks! There has been something bugging me about this since it appeared and that is it. True its an 'auto' but an auto what? Auto scope? Auto Type? Auto mobile? Auto initialization? Simply, 'auto' is way too ambiguous. At least 'var' is more focused.
>>>>>
>>>>> --Derek Parnell Melbourne, Australia
>>>>
>>>> I prefer auto for auto typing rather than for auto destruction. Preferences...
>>>
>>>
>>> But that's my point ... 'auto' by itself is ambiguous and for a first-timer to understand it depends somewhat on one's preconceptions and preferences.
>>
>> I agree.
>>
>> auto for types is barely bearable. But something better should be invented. Personally I'd even settle for "var", in the worst case.
>>
Hmm... now that I think about it, what about "autotype?"
>> auto for RAII is not even barely bearable. We could even use "raii" rather than "auto". At least it wouldn't be ambiguous or opaque.
> I second that; it would certainly make more sense.
> 

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4403B499.2060300@nospam.org...
> auto for RAII is not even barely bearable. We could even use "raii" rather than "auto".

Why not "rr"?

Oh Georg, your personal acronyms ;)

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:du0hqu$a7i$1@digitaldaemon.com...
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4403B499.2060300@nospam.org...
>> auto for RAII is not even barely bearable. We could even use "raii" rather than "auto".

On a more serious note, I think auto for RAII makes some sense.  After all, the original meaning of auto in C is that the variable gets "cleaned up" and "goes away" when the scope exits.  The same applies for RAII, although perhaps since there has been an acronym invented to describe this behavior, it should be used instead.

Though I will have to say that "auto" looks prettier than "raii."

"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.

'var' would be a digression into pascalishness (ugh <g>).

"Walter Bright" <newshound@digitalmars.com> wrote in message news:du0sll$lj0$1@digitaldaemon.com...
>
> "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.

Do you mean the two seemingly different "auto"s are not ambigious?

> 'var' would be a digression into pascalishness (ugh <g>).

I'm just glad you didn't use this argument against array slicing ; )

L.