> On the other hand, "as type" reminds me as BASIC, but not in a good way.

You have any good memories from BASIC?
If "as" is associated with basic, it'll never be excepted :-)

L.

"Lionello Lunesu" <lio@lunesu.removethis.com> wrote in message news:d2iphk$304d$1@digitaldaemon.com...
>> It looks a little wierd to me to type
>>    ubyte* x = malloc(100) as (ubyte*);
>> It's not C-like enough. Why change something that ain't broke?
>
> That's a funny one :-)
> It's not C enough! Seems that there are two camps here: those that think
> D's too much C (probably java programmers?) and those that think it's not
> C enough (those that love STL?).

C and C++ are very different. D should keep as close to C as possible and use C++ and Java/C# as sources of ideas.

> But really, what about "if (A is B)"? or "if (c in AA)" ? Do we need strange tokens for all operations? I think "as" fits in nicely, being a two letter keyword. Not many clashes, not a useful variable name either: "int as;" has no meaning (as opposed to "length" etc..).

There is no equivalent to "is" and "in" in C. Casting is a well-known concept in C/C++/Java/C# so straying too far from those languages significantly will cause confusion.

> And the "ain't broke", depends who you ask. (whom you ask? :-S)
> I still think cast(ubyte*)malloc(100) looks like two function calls, whose
> results are somehow combined. I know it works, it used it too, no problems
> there, but it just looks strange. It's something 'new', a new syntax, and
> I hate new stuff :-/

It's perfectly fine to not like a syntax. And it's perfectly fine to suggest alternatives. I believe, though, in this case the current syntax is the best alternative yet proposed. As someone else said it is familiar and easily parsable/greppable/etc. These things are always judgement calls so people who come to different conclusions are just weighing the factors differently.

> There is no equivalent to "is" and "in" in C. Casting is a well-known concept in C/C++/Java/C# so straying too far from those languages significantly will cause confusion.

I was referring to D and I've used "is" and "in" as examples where the Java/C# path was chosen instead of the C/C++ ("let's use a symbol! is $ used?") route.

> It's perfectly fine to not like a syntax. And it's perfectly fine to suggest alternatives. I believe, though, in this case the current syntax is the best alternative yet proposed. As someone else said it is familiar and easily parsable/greppable/etc. These things are always judgement calls so people who come to different conclusions are just weighing the factors differently.

True. Now I wonder what reasons where given to add "is" to the language,
where we already had "===" for the same thing.
(And as far as greppability is concerned: "as" is just as greppable;
parsability? I don't know much about parsing)

L.

> True. Now I wonder what reasons where given to add "is" to the language, where we already had "===" for the same thing.

It was added in Nov 2003 - here's the archive around that time http://www.digitalmars.com/d/archives/18188.html

Ben Hinkle wrote:

>>True. Now I wonder what reasons where given to add "is" to the language, where we already had "===" for the same thing.
> 
> It was added in Nov 2003 - here's the archive around that time
> http://www.digitalmars.com/d/archives/18188.html

Here's hoping that they can all be left in, even if redundant...
But maybe that's just the Perl guy in me speaking ? (TIMTOWTDI)

But I think it can be useful to have all of "is", "in" and "as" -
even if there are perfectly good other ways to accomplish those:

* "is" is needed, since some people find '===' confusing.
  (even though there is no pretty alternative for '!==')

* "in" is needed, since the hash[key] lookup is broken*...
  (even though it returns a pointer, instead of a bool)

* "as" is needed, since some people don't like cast(type).
  (even though it might look strange, in complex cases)

Hopefully, adding one doesn't mean removing the other one ?
(and if it does, I would still prefer '!==' and 'cast(type)')

--anders

PS.
* I know, I know, it is also needed to separate invalid keys
  from values which happens to have the default value too,
  and to avoid double lookups when both testing and getting.
  (I won't go into that particular topic here, thank you...)
  I meant that it adds new keys, when you just try to read it ?

Thanks.. I'm now trying to find out what the ultimate reason was, so that I can use the same and convice everybody that I'm right... ...right...

L.

>>> It looks a little wierd to me to type
>>>    ubyte* x = malloc(100) as (ubyte*);
>>> It's not C-like enough. Why change something that ain't broke?
>>
>> That's a funny one :-)
>> It's not C enough! Seems that there are two camps here: those that think
>> D's too much C (probably java programmers?) and those that think it's not
>> C enough (those that love STL?).
>
>C and C++ are very different.
Right.

>D should keep as close to C as possible
Why?

>and use C++ and Java/C# as sources of ideas.

So let's take C#'s as-operator!


[quote]
The as operator is like a cast except that it yields null on conversion failure
instead of raising an exception. More formally, an expression of the form:

expression as type

is equivalent to:

expression is type ? (type)expression : (type)null

except that expression is evaluated only once.

Note that the as operator only performs reference conversions and boxing
conversions. The as operator cannot perform other conversions, such as
user-defined conversions, which should instead be performed using cast
expressions.
[/quote]


>> But really, what about "if (A is B)"? or "if (c in AA)" ? Do we need strange tokens for all operations? I think "as" fits in nicely, being a two letter keyword. Not many clashes, not a useful variable name either: "int as;" has no meaning (as opposed to "length" etc..).
>
>There is no equivalent to "is" and "in" in C.
Why is that important? There is no foreach in C. C is a ugly and complicated language. Why should we stay close to that?

>Casting is a well-known concept in C/C++/Java/C# so straying too far from those languages significantly will cause confusion.

So let's get closer by adding an as operator like in C#!



>> And the "ain't broke", depends who you ask. (whom you ask? :-S)
>> I still think cast(ubyte*)malloc(100) looks like two function calls, whose
>> results are somehow combined. I know it works, it used it too, no problems
>> there, but it just looks strange. It's something 'new', a new syntax, and
>> I hate new stuff :-/
>
>It's perfectly fine to not like a syntax. And it's perfectly fine to suggest alternatives. I believe, though, in this case the current syntax is the best alternative yet proposed. As someone else said it is familiar and easily parsable/greppable/etc. These things are always judgement calls so people who come to different conclusions are just weighing the factors differently.

greping for 'cast' is easier than greping 'as'? Could you explain that please?

-- Matthias Becker

>>D should keep as close to C as possible
> Why?
The hard part is deciding what "close" means and "as possible". To quote the web site: "The general look of D is like C and C++. This makes it easier to learn and port code to D. Transitioning from C/C++ to D should feel natural. The programmer will not have to learn an entirely new way of doing things."

>>and use C++ and Java/C# as sources of ideas.
>
> So let's take C#'s as-operator!

As someone already noted the C# cast throws an exception on failure so they needed another operator to do what D's cast does. The fact that C# needs "as" in addition to "cast" to me says they made a mistake. D's "cast" operator does just fine by itself.

>>> But really, what about "if (A is B)"? or "if (c in AA)" ? Do we need
>>> strange tokens for all operations? I think "as" fits in nicely, being a
>>> two letter keyword. Not many clashes, not a useful variable name either:
>>> "int as;" has no meaning (as opposed to "length" etc..).
>>
>>There is no equivalent to "is" and "in" in C.
> Why is that important? There is no foreach in C. C is a ugly and
> complicated
> language. Why should we stay close to that?
For concepts that exist in both C and D we should stay close to the C behavior. The "foreach", "is", and "in" features do not exist in C so the argument that since D has those features it should have "as" is moot. Casting exist in C and so we should stay close to that.

>>Casting is a well-known
>>concept in C/C++/Java/C# so straying too far from those languages
>>significantly will cause confusion.
>
> So let's get closer by adding an as operator like in C#!
see above

>>> And the "ain't broke", depends who you ask. (whom you ask? :-S)
>>> I still think cast(ubyte*)malloc(100) looks like two function calls,
>>> whose
>>> results are somehow combined. I know it works, it used it too, no
>>> problems
>>> there, but it just looks strange. It's something 'new', a new syntax,
>>> and
>>> I hate new stuff :-/
>>
>>It's perfectly fine to not like a syntax. And it's perfectly fine to
>>suggest
>>alternatives. I believe, though, in this case the current syntax is the
>>best
>>alternative yet proposed. As someone else said it is familiar and easily
>>parsable/greppable/etc. These things are always judgement calls so people
>>who come to different conclusions are just weighing the factors
>>differently.
>
> greping for 'cast' is easier than greping 'as'? Could you explain that please?

I didn't say "as" isn't grepable. I said the current behavior is parsable/grepable/etc.

In article <d2jgkd$lpc$1@digitaldaemon.com>, Lionello Lunesu says...
>
>True. Now I wonder what reasons where given to add "is" to the language, where we already had "===" for the same thing.

Personally, I never use "===" because it's too easy to mistype and misread.  In some respects I do like the alternative tokens in C++, even though no one ever uses them: and, bitor, or, xor, etc.


Sean

In article <d2jl9m$qv3$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>* "in" is needed, since the hash[key] lookup is broken*...
>   (even though it returns a pointer, instead of a bool)
..
>PS.
>* I know, I know, it is also needed to separate invalid keys
>   from values which happens to have the default value too,
>   and to avoid double lookups when both testing and getting.
>   (I won't go into that particular topic here, thank you...)
>   I meant that it adds new keys, when you just try to read it ?

Perhaps it's my background with C++ (std::vector behaves the same way), but I consider this correct behavior.  hash[key] is a valid lvalue, while the result of "in" is not.