Matthew wrote:
>>>If the intention of DigitalMars is to tempt a certain amount of computer
>>>nerds to the language D by promising an open standard and at the same
> 
> time
> 
>>>bind them to a proprietary implementation not fully consistent with the
>>>proposed standard and its somehow natural interpretation, then it is
> 
> quite
> 
>>>okay to make even more departures than the two I have detected:
>>>
>>>- the one which is the matter of this thread, and
>>>- the `cast' operator beeing optional in dmd.
>>
>><snip>
>>
>>You're right, that's just what I've been thinking for a while.  There
>>does seem to be both an inconsistency and a deviation from CFG with casts.
> 
> I think the cast operator should be mandatory

I absolutely agree. It has to be now. Before D 1.0 is set and we have a bunch of legacy code with C-style casts hanging around.

-- 
Justin
http://jcc_7.tripod.com/d/

"J C Calvarese" <jcc7@cox.net> wrote in message news:c38i7b$un$1@digitaldaemon.com...
> Matthew wrote:
> >>>If the intention of DigitalMars is to tempt a certain amount of
computer
> >>>nerds to the language D by promising an open standard and at the same
> >
> > time
> >
> >>>bind them to a proprietary implementation not fully consistent with the proposed standard and its somehow natural interpretation, then it is
> >
> > quite
> >
> >>>okay to make even more departures than the two I have detected:
> >>>
> >>>- the one which is the matter of this thread, and
> >>>- the `cast' operator beeing optional in dmd.
> >>
> >><snip>
> >>
> >>You're right, that's just what I've been thinking for a while.  There does seem to be both an inconsistency and a deviation from CFG with
casts.
> >
> > I think the cast operator should be mandatory
>
> I absolutely agree. It has to be now. Before D 1.0 is set and we have a bunch of legacy code with C-style casts hanging around.

Quite right. Let me presumptuously institute a vote.

Stewart Gordon wrote:

[...]
> "There are no digraphs or trigraphs in D. The source text is split into tokens using the maximal munch technique, i.e., the lexical analyzer tries to make the longest token it can. For example >> is a right shift token, not two greater than tokens."

Thanks for this link.


> But if that's exactly true, then from the way string literals are specified, surely in
> 
> 	qwert("yuiop", "asdfg")
> 
> a single, 14-character string is being passed?

Right. It should be specified, that allowed characters do not include the delimiting `"' or ``'.


> I think what it should have in mind is making the spec clearer.  You're right, there's nothing suggesting that 2..4 should be 2 .. 4 and not 2. .4 or even any of the three other possibilities.

I see five, but only when not using longest match.


[...]

So long!

Manfred Nowak wrote:

<snip>
>> I think what it should have in mind is making the spec clearer.
>> You're right, there's nothing suggesting that 2..4 should be 2 .. 4
>> and not 2. .4 or even any of the three other possibilities.
> 
> I see five, but only when not using longest match.

2. . 4
2 . .4
2 . . 4

Of course, the character sequence could be split up as

2.. 4
2 ..4

but these involve what aren't valid D tokens.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

[...]
> but these involve what aren't valid D tokens.

Agreed. I did not think of this argument.

So long!