Andrei Alexandrescu wrote:
> Robert Jacques wrote:
>>>> long g;
>>>> g = e + f;  => d = cast(long) e + cast(long) f;
>>>
>>> Works today.
>>
>> Wrong. I just tested this and what happens today is:
>> g = cast(long)(e+f);
>> And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.
> 
> I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=".

It's also troublesome because it would silently produce different answers than C would.

Andrei Alexandrescu, el  7 de julio a las 16:54 me escribiste:
> Leandro Lucarella wrote:
> >Andrei Alexandrescu, el  7 de julio a las 15:12 me escribiste:
> >>Leandro Lucarella wrote:
> >>>Andrei Alexandrescu, el  7 de julio a las 10:56 me escribiste:
> >>>>Leandro Lucarella wrote:
> >>>>>This seems nice. I think it would be nice if this kind of things are commented in the NG before a compiler release, to allow community input and discussion.
> >>>>Yup, that's what happened to case :o).
> >>>>
> >>>>>I think this kind of things are the ones that deserves some kind of RFC (like Python PEPs) like someone suggested a couple of days ago.
> >>>>I think that's a good idea. Who has the time and resources to set that up?
> >>>What's wrong with the Wiki?
> >>Where's the link?
> >I mean the D Wiki!
> >http://prowiki.org/wiki4d/wiki.cgi
> >(BTW, nice job with the Wiki for whoever did it, I don't remember who was
> >putting a lot of work on improving the Wiki, but it's really much better
> >organized now)
> >I think we can add a DIP (D Improvement Proposal =) section in the
> >"Language Development" section:
> >http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel
> 
> Great idea. I can only hope the technical level will be much higher than the two threads related to switch.

I think proposals should be published there but discussed here, so be ready for all kind of discussions (the ones you like and the ones you don't =). From time to time, when there is some kind of agreement, the proposal should be updated (with a new "revision number").

I just went wild and added a DIP index[1] and the first DIP (DIP1), a template for creating new DIPs[2].

This are just rought drafts, but I think they are good enought to start with. Comments are apreciated.

I will post a "formal" announcement too.

[1] http://www.prowiki.org/wiki4d/wiki.cgi?DiPs
[2] http://www.prowiki.org/wiki4d/wiki.cgi?DiP1

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
"The Guinness Book of Records" holds the record for being the most stolen book in public libraries

Derek Parnell wrote:
> Here is where I propose having a signal to the compiler about which
> specific variables I'm worried about, and if I code an assignment to one of
> these that can potentially overflow, then the compiler must issue a
> message. 

You can implement that as a library. In fact I wanted to do it for Phobos for a long time. I've discussed it in this group too (to an unusual consensus), but I forgot the thread's title and stupid Thunderbird "download 500 headers at a time forever even long after have changed that idiotic default option" won't let me find it.


Andrei

On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Robert Jacques wrote:
>>>> long g;
>>>> g = e + f;  => d = cast(long) e + cast(long) f;
>>>
>>> Works today.
>>  Wrong. I just tested this and what happens today is:
>> g = cast(long)(e+f);
>> And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.
>
> I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=".
>
>
> Andrei

Hmm... why can't multiple expressions be built simultaneously and then the best chosen once the assignment/function call/etc is reached? This would also have the benifet of paving the way for polysemous values & expressions.

Robert Jacques wrote:
> On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Robert Jacques wrote:
>>>>> long g;
>>>>> g = e + f;  => d = cast(long) e + cast(long) f;
>>>>
>>>> Works today.
>>>  Wrong. I just tested this and what happens today is:
>>> g = cast(long)(e+f);
>>> And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.
>>
>> I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=".
>>
>>
>> Andrei
> 
> Hmm... why can't multiple expressions be built simultaneously and then the best chosen once the assignment/function call/etc is reached? This would also have the benifet of paving the way for polysemous values & expressions.

Anything can be done... in infinite time with infinite resources. :o)

Andrei

On Tue, 07 Jul 2009 20:13:40 -0500, Andrei Alexandrescu wrote:

> Derek Parnell wrote:
>> Here is where I propose having a signal to the compiler about which specific variables I'm worried about, and if I code an assignment to one of these that can potentially overflow, then the compiler must issue a message.
> 
> You can implement that as a library. In fact I wanted to do it for Phobos for a long time.

What does "implement that as a library" actually mean?

Does it mean that a Phobos module could be written that defines a struct template (presumably) that holds the data and implements opAssign, etc... to issue a message if required. I assume it could do some limited compile-time value tests so it doesn't always have to issue a message.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Andrei Alexandrescu wrote:
> You can implement that as a library. In fact I wanted to do it for Phobos for a long time. I've discussed it in this group too (to an unusual consensus), but I forgot the thread's title and stupid Thunderbird "download 500 headers at a time forever even long after have changed that idiotic default option" won't let me find it.

All the messages from the dawn of time are online and available at http://www.digitalmars.com/d/archives/digitalmars/D/ and are searchable from the search box in the upper left.

On Tue, 07 Jul 2009 18:43:41 -0300, Leandro Lucarella wrote:

> 
> (BTW, nice job with the Wiki for whoever did it, I don't remember who was putting a lot of work on improving the Wiki, but it's really much better organized now)

Hi, thanks.

> I think we can add a DIP (D Improvement Proposal =) section in the "Language Development" section: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel

I was reusing the Discussion and Ideas for these things, but DIP could be for those brought forward by the involved few of accepting ideas, since Ideas and Discussion will likely end up with a lot of old or less thought out ideas.

http://www.prowiki.org/wiki4d/wiki.cgi?IdeaDiscussion

On Tue, 07 Jul 2009 21:21:47 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Robert Jacques wrote:
>> On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Robert Jacques wrote:
>>>>>> long g;
>>>>>> g = e + f;  => d = cast(long) e + cast(long) f;
>>>>>
>>>>> Works today.
>>>>  Wrong. I just tested this and what happens today is:
>>>> g = cast(long)(e+f);
>>>> And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.
>>>
>>> I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=".
>>>
>>>
>>> Andrei
>>  Hmm... why can't multiple expressions be built simultaneously and then the best chosen once the assignment/function call/etc is reached? This would also have the benifet of paving the way for polysemous values & expressions.
>
> Anything can be done... in infinite time with infinite resources. :o)
>
> Andrei

:) Well, weren't polysemous expressions already in the pipeline somewhere?

Robert Jacques wrote:
> On Tue, 07 Jul 2009 21:21:47 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Robert Jacques wrote:
>>> On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>>
>>>> Robert Jacques wrote:
>>>>>>> long g;
>>>>>>> g = e + f;  => d = cast(long) e + cast(long) f;
>>>>>>
>>>>>> Works today.
>>>>>  Wrong. I just tested this and what happens today is:
>>>>> g = cast(long)(e+f);
>>>>> And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.
>>>>
>>>> I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=".
>>>>
>>>>
>>>> Andrei
>>>  Hmm... why can't multiple expressions be built simultaneously and then the best chosen once the assignment/function call/etc is reached? This would also have the benifet of paving the way for polysemous values & expressions.
>>
>> Anything can be done... in infinite time with infinite resources. :o)
>>
>> Andrei
> 
> :) Well, weren't polysemous expressions already in the pipeline somewhere?

I'm afraid they didn't get wings. We have incidentally found different ways to address the issues they were supposed to address.

Andrei