I'm planning to go over druntime and add nothrow/pure everywhere I can, 
but I don't want to disturb anyone else who's currently working on 
patches that this could disrupt.

-- 
- Alex

On Wed, Apr 11, 2012 at 12:10:19AM +0200, Alex Rønne Petersen wrote:
> I'm planning to go over druntime and add nothrow/pure everywhere I
> can, but I don't want to disturb anyone else who's currently working
> on patches that this could disrupt.
[...]

Please do. The current lack of proper function qualifiers has been
bugging me to no end, every time I try to do the same in my own code. I
inevitably have to remove some qualifiers that should be there, just
because of a single druntime construct that wasn't properly qualified.

And while you're at it, you might want to consider const too. Last I
looked, a whole bunch of stuff that should be const, isn't.

And best of luck to you... the last time I tried to do the same thing I
ended up changing almost the entire druntime, and still couldn't get the
result to compile.


T

-- 
"I speak better English than this villain Bush" -- Mohammed Saeed al-Sahaf, Iraqi Minister of Information

On 11-04-2012 01:09, H. S. Teoh wrote:
> On Wed, Apr 11, 2012 at 12:10:19AM +0200, Alex Rønne Petersen wrote:
>> I'm planning to go over druntime and add nothrow/pure everywhere I
>> can, but I don't want to disturb anyone else who's currently working
>> on patches that this could disrupt.
> [...]
>
> Please do. The current lack of proper function qualifiers has been
> bugging me to no end, every time I try to do the same in my own code. I
> inevitably have to remove some qualifiers that should be there, just
> because of a single druntime construct that wasn't properly qualified.
>
> And while you're at it, you might want to consider const too. Last I
> looked, a whole bunch of stuff that should be const, isn't.
>
> And best of luck to you... the last time I tried to do the same thing I
> ended up changing almost the entire druntime, and still couldn't get the
> result to compile.
>
>
> T
>

Yeah, I've made several attempts in the past without much luck... 
Hopefully I'll get there at some point.

So, I won't disrupt your AA hacking by doing this?

-- 
- Alex

On Apr 10, 2012 7:08 PM, "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
>
> On Wed, Apr 11, 2012 at 12:10:19AM +0200, Alex Rønne Petersen wrote:
> > I'm planning to go over druntime and add nothrow/pure everywhere I
> > can, but I don't want to disturb anyone else who's currently working
> > on patches that this could disrupt.
> [...]
>
> Please do. The current lack of proper function qualifiers has been
> bugging me to no end, every time I try to do the same in my own code. I
> inevitably have to remove some qualifiers that should be there, just
> because of a single druntime construct that wasn't properly qualified.
>
> And while you're at it, you might want to consider const too. Last I
> looked, a whole bunch of stuff that should be const, isn't.
>
> And best of luck to you... the last time I tried to do the same thing I
> ended up changing almost the entire druntime, and still couldn't get the
> result to compile.
>
>
> T
>
> --
> "I speak better English than this villain Bush" -- Mohammed Saeed
al-Sahaf, Iraqi Minister of Information

I was wondering why they could not be implied from the code itself.

On Wed, Apr 11, 2012 at 01:09:48AM +0200, Alex Rønne Petersen wrote:
> On 11-04-2012 01:09, H. S. Teoh wrote:
> >On Wed, Apr 11, 2012 at 12:10:19AM +0200, Alex Rønne Petersen wrote:
> >>I'm planning to go over druntime and add nothrow/pure everywhere I
> >>can, but I don't want to disturb anyone else who's currently working
> >>on patches that this could disrupt.
> >[...]
> >
> >Please do. The current lack of proper function qualifiers has been
> >bugging me to no end, every time I try to do the same in my own code. I
> >inevitably have to remove some qualifiers that should be there, just
> >because of a single druntime construct that wasn't properly qualified.
> >
> >And while you're at it, you might want to consider const too. Last I
> >looked, a whole bunch of stuff that should be const, isn't.
> >
> >And best of luck to you... the last time I tried to do the same thing I
> >ended up changing almost the entire druntime, and still couldn't get the
> >result to compile.
> >
> >
> >T
> >
> 
> Yeah, I've made several attempts in the past without much luck...
> Hopefully I'll get there at some point.
> 
> So, I won't disrupt your AA hacking by doing this?
[...]

No, I'm doing the new AA as a completely separate struct for now. I
won't be touching druntime until the AA code itself is more-or-less
completed. Once that's done, it should be just a matter of
copy-n-pasting into object_.d with some minor changes (plus what's
anticipated to be very painful dmd changes, from what people have been
telling me :-P).

In fact, if druntime stuff is properly marked, I'll be able to uncomment
a few more qualifiers in the AA code that currently can't work 'cos of
druntime's brokenness.


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the "window".

On 11-04-2012 01:29, H. S. Teoh wrote:
> On Wed, Apr 11, 2012 at 01:09:48AM +0200, Alex Rønne Petersen wrote:
>> On 11-04-2012 01:09, H. S. Teoh wrote:
>>> On Wed, Apr 11, 2012 at 12:10:19AM +0200, Alex Rønne Petersen wrote:
>>>> I'm planning to go over druntime and add nothrow/pure everywhere I
>>>> can, but I don't want to disturb anyone else who's currently working
>>>> on patches that this could disrupt.
>>> [...]
>>>
>>> Please do. The current lack of proper function qualifiers has been
>>> bugging me to no end, every time I try to do the same in my own code. I
>>> inevitably have to remove some qualifiers that should be there, just
>>> because of a single druntime construct that wasn't properly qualified.
>>>
>>> And while you're at it, you might want to consider const too. Last I
>>> looked, a whole bunch of stuff that should be const, isn't.
>>>
>>> And best of luck to you... the last time I tried to do the same thing I
>>> ended up changing almost the entire druntime, and still couldn't get the
>>> result to compile.
>>>
>>>
>>> T
>>>
>>
>> Yeah, I've made several attempts in the past without much luck...
>> Hopefully I'll get there at some point.
>>
>> So, I won't disrupt your AA hacking by doing this?
> [...]
>
> No, I'm doing the new AA as a completely separate struct for now. I
> won't be touching druntime until the AA code itself is more-or-less
> completed. Once that's done, it should be just a matter of
> copy-n-pasting into object_.d with some minor changes (plus what's
> anticipated to be very painful dmd changes, from what people have been
> telling me :-P).
>
> In fact, if druntime stuff is properly marked, I'll be able to uncomment
> a few more qualifiers in the AA code that currently can't work 'cos of
> druntime's brokenness.
>
>
> T
>

Excellent. I'll get to it then. :)

-- 
- Alex

Le 11/04/2012 00:10, Alex Rønne Petersen a écrit :
> I'm planning to go over druntime and add nothrow/pure everywhere I can,
> but I don't want to disturb anyone else who's currently working on
> patches that this could disrupt.
>

Can't we consider this as an inference issue ?

"Kevin Cox" <kevincox.ca@gmail.com> wrote in message 
news:mailman.1599.1334099575.4860.digitalmars-d@puremagic.com...
>
>I was wondering why they could not be implied from the code itself.

That question comes up a lot. The thing is, that would completely defeat the 
point. The point is that you want the compiler to *guarantee* that certain 
specific functions are pure/@safe/const/nothrow, etc.

If you make a change that prevents a function from being 
pure/@safe/const/nothrow, and the compiler just simply accepted it and 
internally considered it non-pure/non-whatever, then you haven't gained 
anything at all. It'd be no different from not even having any 
pure/@safe/const/nothrow system in the first place. At *best* it would just 
be a few optimizations here and there.

But if the compiler tells you, "Hey, you said you wanted this function to be 
pure/whatever, but you're doing X which prevents that", then you can 
actually *fix* the problem and go make it pure/whatever.

On Apr 11, 2012 4:14 PM, "Nick Sabalausky" <
SeeWebsiteToContactMe@semitwist.com> wrote:
>
> "Kevin Cox" <kevincox.ca@gmail.com> wrote in message
> news:mailman.1599.1334099575.4860.digitalmars-d@puremagic.com...
> >
> >I was wondering why they could not be implied from the code itself.
>
> That question comes up a lot. The thing is, that would completely defeat
the
> point. The point is that you want the compiler to *guarantee* that certain
> specific functions are pure/@safe/const/nothrow, etc.
>
> If you make a change that prevents a function from being
> pure/@safe/const/nothrow, and the compiler just simply accepted it and
> internally considered it non-pure/non-whatever, then you haven't gained
> anything at all. It'd be no different from not even having any
> pure/@safe/const/nothrow system in the first place. At *best* it would
just
> be a few optimizations here and there.
>
> But if the compiler tells you, "Hey, you said you wanted this function to
be
> pure/whatever, but you're doing X which prevents that", then you can
> actually *fix* the problem and go make it pure/whatever.
>

Makes sense.

On Wednesday, April 11, 2012 22:01:36 deadalnix wrote:
> Le 11/04/2012 00:10, Alex Rønne Petersen a écrit :
> > I'm planning to go over druntime and add nothrow/pure everywhere I can,
> > but I don't want to disturb anyone else who's currently working on
> > patches that this could disrupt.
> 
> Can't we consider this as an inference issue ?

How so? Attribute inference exists only for templated functions and some 
delegate stuff. We're talking primarily about extern(C) function declarations 
here.

- Jonathan M Davis