"Walter" <newshound@digitalmars.com> wrote in message news:cvuq59$2agl$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:cvuku9$24j5$1@digitaldaemon.com...
>> But the reverse is true
>> for other integral conversions. They happen frequently, legitimately.
> Having
>> to insert casts for them means you'll wind up with a lot of casts in the code.
>
> An example is in order:
>
>    byte b;
>    ...
>    b = b + 1;
>
> That gives an error if implicit narrowing conversions are disallowed. You'd have to write:
>
>    b = cast(byte)(b + 1);
>
> or, if writing generic code:
>
>    b = cast(typeof(b))(b + 1);
>
> Yuk.

Sorry, but that's only required if all integral expressions must be promoted to (at least) int. Who says that's the one true path? Why is int the level at which it's drawn? Why can there not a bit more contextual information applied?

Is there no smarter way of dealing with it?

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:cvuuh5$2evh$1@digitaldaemon.com...
>>> But the reverse is true
>>> for other integral conversions. They happen frequently, legitimately.
>>Having
>>> to insert casts for them means you'll wind up with a lot of casts in the code.
>>
>>An example is in order:
>>
>>    byte b;
>>    ...
>>    b = b + 1;
>>
>>That gives an error if implicit narrowing conversions are disallowed. You'd have to write:
>>
>>    b = cast(byte)(b + 1);
>>
>>or, if writing generic code:
>>
>>    b = cast(typeof(b))(b + 1);
>>
>>Yuk.
>>
>
> The type of string literals is infered by the context. Couldn't this be done with integer lietrals, too? If byte + byte results in byte the above wouldn't be a problem.

Alas, it's a little more complex than that. byte+byte would have to result in ushort, since byte+byte can overflow byte. This in itself is an implicit narrowing conversion.

But the example itself is bogus. Let's look at it again, with a bit more flesh:

    byte b;

    b = 255

    b = b + 1;

Hmmm .... do we still want that implicit behaviour? I think not!!

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:cvuqnu$2b05$1@digitaldaemon.com...
> >Implicit narrowing conversions:
>>
>>> Or that floating=>integral
>>> narrowing is wrong in *all* cases, and integral=>integral narrowing  is
>>> right in *all* cases. Doesn't stand up to common sense.
>>
>>Of course it doesn't stand up to common sense, and it is not what I said. What I did say, perhaps indirectly, is that implicit floating->integral conversions in the wild tend to nearly always be a mistake. For the few cases where it is legitimate, a cast can be used. But the reverse is true for other integral conversions. They happen frequently, legitimately. Having to insert casts for them means you'll wind up with a lot of casts in the code.
>>
>>Having lots of casts in the code results in *less* type safety, not more. Having language rules that encourage lots of casting is not a good idea. Casts should be fairly rare.
>>
>>It isn't all or nothing. It's a judgement call on the balance between the risk of bugs from a narrowing conversion and the risk of bugs from a cast masking a totally wrong type. With integral conversions, it falls on the one side, with floating conversions, it falls on the other.
>
> When I get a warning from my C++ compiler that I do a narrowing conversation I allways insert a cast.

Do you mean, "after considering whether the code is correct"? If not, the you add grist to Walter's mill that narrowing errors just precipiate the careless (ab)use of casts. (Which I don't believe.)

In article <cvuvsd$2gdd$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Matthias Becker wrote:
>
>> The type of string literals is infered by the context. Couldn't this be done with integer lietrals, too? If byte + byte results in byte the above wouldn't be a problem.
>
>Converting string literals is not narrowing, it's round-trip...

Infering the type of strings isn't narrowing, right, but infering the type of integers isn't neigther. Infering the type has nothing to do with narrowing at all.

-- Matthias Becker

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4222DA20.2030206@nospam.org...
>
>
> Matthew wrote:
>> "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:42225D39.7010302@nospam.org...
>
> (lots of good and to-the-point stuff deleted) (also points
> taken)  :-)
>
>>     (iv) the potential for D to be better, or rather to better
>> support, template programming without the necessary intellectual pain
>> that goes on in C++
>
> We really do need to somehow get a grip on what's needed for templates!! In a couple of posts I've tried to find out exactly what the requirements for a (superior? superlative? -- aw crap, just well working) template system are.
>
> What I'd wish is a discussion about what kinds of things
> people see a template system should bring. Like instead
> of how we can tweak the existing one, we'd start from
> scratch -- at least with the thinking and discussion.
>
> I also somehow feel that we'd need to try out some of the better ideas. At least the syntax could be tried out with preprocessors (to some extent at least).
>
> Matthew, (as the best qualified in this particular subject) what would you really wish a "perfect" template system could do? Like if you were granted Any Three Wishes style.

Here's where my particular talents/disabilities cause a problem, for me at least. My brain just doesn't work the way (that I suspect) that most other engineers' do. I barely retain a conscious cognisance of the terms 'parameterisation' and 'instantiation' - anything deeper than that in a conversational context leaves me wandering around in a mental fog.

I'm afraid I am a do-er - I believe it's more formally known as kinetic form thinking -  and as such will be thoroughly unqualified to comment/request/philosophise until such time as I dive back into DTL. Thankfully, that time is very close. (Although it may seem to (any interested parties in) the outside world that I've been thumb twiddling over the last few months, but the truth is quite the opposite: I've been working through lots of core stuff with my libraries, and also formulating ideas, strategies and automated tools.)

So, I am confident that I'll be heavily back in DTL next month (March), and will make good progress. I'll be full of all kinds of fun then. :-)

>> I do not *believe* that it will become all that it can, anymore than I *believe* my sons will grow up to be Nobel prize-winning physicists, or that Imperfect C++ will eventually be recognised as better for developers than some recent C++ books that like to make the reader feel inferior with all manner of nonsensical intellectual masturbation. I just think these things are not beyond the bounds of reason.
>
> Oh, Bob! What if my sons don't either???    {8-O

Then we'll just have to hope they're happy. (Which'll probably be the better outcome anyway)

Matthew wrote:
> But the example itself is bogus. Let's look at it again, with a bit more flesh:
> 
>     byte b;
> 
>     b = 255
> 
>     b = b + 1;
> 
> Hmmm .... do we still want that implicit behaviour? I think not!!

int big;
big = A_BIG_LITERAL_VALUE;
big = big + 1; // or any value at all, actually.

Where's the difference?

If somebody typed b as byte, then it's his own decision. Anyone using a small integral type has to know they can overflow -- this is no place for nannying.

Heck, any integral type might overflow.

(What I'd love is a switch for non-release code to check for overflow!)

Matthew wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message 

>>Matthew, (as the best qualified in this particular subject)
>>what would you really wish a "perfect" template system
>>could do? Like if you were granted Any Three Wishes style.
> 
> 
> Here's where my particular talents/disabilities cause a problem, for me at least. My brain just doesn't work the way (that I suspect) that most other engineers' do. I barely retain a conscious cognisance of the terms 'parameterisation' and 'instantiation' - anything deeper than that in a conversational context leaves me wandering around in a mental fog.
> 
> I'm afraid I am a do-er - I believe it's more formally known as kinetic form thinking -  and as such will be thoroughly unqualified to comment/request/philosophise until such time as I dive back into DTL. 

I may end up with some customer before long, so I'm pursuing this hard right now.

So, instead, what was the last thing you would've done, except it was too hard/impossible with the current template system. (Either in D or in C++ !)

I could also use snippets of code, as you would have written them (given a better D/C++ cpp).

>>
>>Oh, Bob! What if my sons don't either???    {8-O
> 
> 
> Then we'll just have to hope they're happy. (Which'll probably be the better outcome anyway)

Yeah. At times I feel that is a challenge. Give a toy, and they're happy for the day. But what to do to get them happy _for the rest of their lives_?   ((Er, this was _rhetorical_, so don't nobody answer this, or we'll get a thread that'll wipe off D from this ng. And still end up back at square one.))

Matthias Becker wrote:

> Infering the type of strings isn't narrowing, right, but infering the type of
> integers isn't neigther. Infering the type has nothing to do with narrowing at
> all.

I don't think that D infers the type of integer literals at all...
They're all "int" due to C tradition ? Maybe stupid, but so be it.

Strings are all char[], but can be interpreted as wchar[] and dchar[]
too for special uses (although it is only implicit for string literals)


If D should have some way of specifying smaller literals too, it would
have to be added to the language. Right now, they're either int or long.

Like Walter said: "a string literal begins life with no type", but
integer literals (without L) still begins life being of the type: int.


Are you saying all integers (lit.) should start without a type as well ?
(equally likely to convert into byte/short/int, depending on context)

Maybe I am misunderstanding something, but I think the casts work...
The integer promotions are part of the C legacy built into the design.


They also happen to map nicely onto 32-bit registers, which my CPU has.
(the new computer actually has 64-bit and 128-bit registers too :-D )

--anders

"Derek" <derek@psych.ward> wrote in message news:1uxqa6iv5mgq3.hjei032qxzwk.dlg@40tude.net...
> On Mon, 28 Feb 2005 02:01:18 -0800, Walter wrote:
>
> > "Walter" <newshound@digitalmars.com> wrote in message
> >     b = cast(typeof(b))(b + 1);
>
> Unless the '1' was interpreted to be a byte rather than an int. DMD gives up trying to soon. A '1' is a member of many integer subsets, not just the 'int' subset.

Even if the '1' was typed as a byte, such as with a cast, you'd still have to write:

    b = cast(typeof(b))(b + cast(typeof(b))1);

because of the integral promotion rules: given (e1 + e2), both are promoted to ints or uints if they are integral types smaller than ints or uints. The integral promotion rules are taken from C, and I believe it would be a huge mistake to try and rewrite them.

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4222F9DA.1020707@nospam.org...
> I assume this is because of Natural number literals being integers?

No. The same issue happens even with:

    byte a,b;
    b = a + b;

It's because of the "default integral promotions".

> Now,
> there's a gratuituous widening implicit cast -- which then results to
> the narrowing cast later, right?
>
> I'd wish such literals get implicitly cast to the type "needed". Or better yet, cast to the smallest possible type.

What you're suggesting is called top down type inference, rather than bottom up type inference. Currently, there are a couple cases in D (and C++) where top down inference is used. The two together cause conflicts. It causes a lot of trouble with overloading, and it may not be possible to ever get it working in a reasonable manner.