2010/8/30 Andrei Alexandrescu
> On 8/30/10 14:16 PDT, Tomek Sowiński wrote:
>
>> Dnia 30-08-2010 o 21:10:10 Tomek Sowiński napisał(a):
>>
>> How about reduce!fun(range)? It's pure/nothrow when fun is
>>> pure/nothrow. Plenty of std.algorithm would benefit.
>>>
>>
>> Eh, nevermind. popFront() mu
Dnia 30-08-2010 o 21:16:15 Tomek Sowiński napisał(a):
Dnia 30-08-2010 o 21:10:10 Tomek Sowiński napisał(a):
How about reduce!fun(range)? It's pure/nothrow when fun is
pure/nothrow. Plenty of std.algorithm would benefit.
Eh, nevermind. popFront() must mutate the range so it can't be pure.
On 8/30/10 14:16 PDT, Tomek Sowiński wrote:
Dnia 30-08-2010 o 21:10:10 Tomek Sowiński napisał(a):
How about reduce!fun(range)? It's pure/nothrow when fun is
pure/nothrow. Plenty of std.algorithm would benefit.
Eh, nevermind. popFront() must mutate the range so it can't be pure.
Need to get s
Dnia 30-08-2010 o 21:10:10 Tomek Sowiński napisał(a):
How about reduce!fun(range)? It's pure/nothrow when fun is pure/nothrow.
Plenty of std.algorithm would benefit.
Eh, nevermind. popFront() must mutate the range so it can't be pure. Need
to get some sleep...
Dnia 29-08-2010 o 06:57:17 Brad Roberts napisał(a):
On 8/28/2010 6:29 PM, dsimcha wrote:
An issue that comes up very frequently when trying to use const, pure or
nothrow in generic code is lack of knowledge of whether the functions
you're
calling are const/pure/nothrow. For example:
T abs
== Quote from Pillsy (pillsb...@gmail.com)'s article
> Andrei Alexandrescu Wrote:
> > On 08/28/2010 08:29 PM, dsimcha wrote:
> > > An issue that comes up very frequently when trying to use
> > > const, pure or nothrow in generic code is lack of knowledge
> > > of whether the functions you're callin
Andrei Alexandrescu Wrote:
> On 08/28/2010 08:29 PM, dsimcha wrote:
> > An issue that comes up very frequently when trying to use
> > const, pure or nothrow in generic code is lack of knowledge
> > of whether the functions you're calling are
> > const/pure/nothrow. For example:
> > T abs(T n
Simen kjaeraas:
> Please do elucidate.
I am not able to design user-defined attributes in a short time all alone :-)
I'd like to be able to define scoped attributes in normal D code, so you can
extend a bit the D type system in user-code, using static introspection (using
__traits and other thin
bearophile wrote:
Simen kjaeraas:
I suggest the syntax
@auto[ ]
where is a comma-separated list of @ributes.
That's bad. I prefer a more flexible semantics, so @auto becomes one
case of user-defined scoped properties.
Please do elucidate. Does the second part of my post perhaps he
Simen kjaeraas:
> I suggest the syntax
> @auto[ ]
> where is a comma-separated list of @ributes.
That's bad. I prefer a more flexible semantics, so @auto becomes one case of
user-defined scoped properties.
Bye,
bearophile
On 8/29/2010 08:44, Robert Jacques wrote:
> So... dynamic libraries (DLL's, etc.) are an archaic compilation model?
> Might you be able to suggest an newer alternative? (that doesn't involve
> a JIT, of course)
Not necessarily, but it /is/ a special case. Dlls are best treated as
separate program
Andrej Mitrovic wrote:
Couldn't you reuse the version statement for that? At least for a
group of attribute-related functions this might work
Static if, at least. Still, that is the road to extreme code bloat.
Imagine having to write those for all combinations of pure,
nothrow, const/immutabl
Couldn't you reuse the version statement for that? At least for a
group of attribute-related functions this might work (but I haven't
tried):
version(pure)
{
@pure
void foo() {...}
@pure
void bar() {...}
}
else
{
void foo() {...}
void bar() {...}
}
For this, I suggest the
dsimcha wrote:
[Interesting stuff]
This problem is much bigger that @auto. When we get a new @ribute
that affects code in a similar way, are we to add @autofnord @autogrok
@autogazillions to the language as well? If anything, this system should
be made extensible. I suggest the syntax
@aut
Justin Johansson:
> Is the reason for this due to some optimization strategy to
> avoid copying and changing the sign on the copy?
If each of your numbers need 500 MB of RAM, copying a number just to change its
sign, and then free the original number is a significant waste of time. So it's
an op
== Quote from Robert Jacques (sandf...@jhu.edu)'s article
> On Sun, 29 Aug 2010 00:42:49 -0400, Rainer Deyke
> wrote:
> > On 8/28/2010 22:33, dsimcha wrote:
> >>> Is there any real reason why we can't apply these modifiers
> >>> automatically to all functions? (And by "real" I don't mean "it woul
== Quote from Peter Alexander (peter.alexander...@gmail.com)'s article
> On 29/08/10 2:29 AM, dsimcha wrote:
> > An issue that comes up very frequently when trying to use const, pure or
> > nothrow in generic code is lack of knowledge of whether the functions you're
> > calling are const/pure/nothr
On 29/08/10 2:29 AM, dsimcha wrote:
An issue that comes up very frequently when trying to use const, pure or
nothrow in generic code is lack of knowledge of whether the functions you're
calling are const/pure/nothrow. For example:
T abs(T num) pure nothrow {
return (num< 0) ? -1 * num : n
On Sun, 29 Aug 2010 00:42:49 -0400, Rainer Deyke
wrote:
On 8/28/2010 22:33, dsimcha wrote:
Is there any real reason why we can't apply these modifiers
automatically to all functions? (And by "real" I don't mean "it would
be hard to do" or "it is incompatible with the archaic compilation
m
On 29/08/10 21:36, bearophile wrote:
... if you use multiprecision GNU numbers, your large numbers aren't immutable,
you are able to change their sign in-place.
Is the reason for this due to some optimization strategy to
avoid copying and changing the sign on the copy?
Brad Roberts:
> Abs _should_ be pure. If the type being passed to it is incapable performing
> the algorithm purely, then the type isn't valid to be used with abs.
I agree. On the other hand if you use multiprecision GNU numbers, your large
numbers aren't immutable, you are able to change their
On 08/29/2010 06:42 AM, Rainer Deyke wrote:
On 8/28/2010 22:33, dsimcha wrote:
2. The modifiers are part of a contract and part of the public API. What if
some
function just happens to be pure now, but you consider that an implementation
detail, not part of its specification? Client code may
On 8/29/2010 00:32, Jonathan M Davis wrote:
> Templates are instantiated when you use them. They can't work any other way.
> Normal functions are instantiated where they are declared. Unless you want to
> try and make it so that _all_ functions are instantiated where they are used
> (which IMHO
On Saturday 28 August 2010 21:42:49 Rainer Deyke wrote:
> On 8/28/2010 22:33, dsimcha wrote:
> >> Is there any real reason why we can't apply these modifiers
> >> automatically to all functions? (And by "real" I don't mean "it would
> >> be hard to do" or "it is incompatible with the archaic compi
On 8/28/2010 6:29 PM, dsimcha wrote:
> An issue that comes up very frequently when trying to use const, pure or
> nothrow in generic code is lack of knowledge of whether the functions you're
> calling are const/pure/nothrow. For example:
>
> T abs(T num) pure nothrow {
> return (num < 0) ? -1
"Rainer Deyke" wrote in message
news:i5cogl$31j...@digitalmars.com...
> On 8/28/2010 22:33, dsimcha wrote:
>>> Is there any real reason why we can't apply these modifiers
>>> automatically to all functions? (And by "real" I don't mean "it would
>>> be hard to do" or "it is incompatible with the
On 8/28/2010 22:33, dsimcha wrote:
>> Is there any real reason why we can't apply these modifiers
>> automatically to all functions? (And by "real" I don't mean "it would
>> be hard to do" or "it is incompatible with the archaic compilation model
>> chosen by one D implementation".)
>
> Two reaso
== Quote from Rainer Deyke (rain...@eldwood.com)'s article
> On one hand, this addresses a real need. On the other hand, D is
> already has a serious case featuritis.
With regard to featuritis, I see your point, but IMHO without something like
this
pure and nothrow are the worst kind of extra fe
== Quote from Rainer Deyke (rain...@eldwood.com)'s article
> On 8/28/2010 19:29, dsimcha wrote:
> > Looks pretty good. Won't work with BigInt because opBinary!"*" isn't pure
> > and
> > can't practically be made pure. A solution I propose is to allow the
> > annotations @autoconst, @autopure and
On 8/28/2010 19:29, dsimcha wrote:
> Looks pretty good. Won't work with BigInt because opBinary!"*" isn't pure and
> can't practically be made pure. A solution I propose is to allow the
> annotations @autoconst, @autopure and @autonothrow for template functions.
> These would mean "everything I d
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Yah, with the growing interest in applying qualifiers at a larger scale
> (and making Phobos a good example of such) this is quite timely. I've
> been mulling myself over a similar proposal.
> What I had in mind is a bit
On 08/28/2010 08:29 PM, dsimcha wrote:
An issue that comes up very frequently when trying to use const, pure or
nothrow in generic code is lack of knowledge of whether the functions you're
calling are const/pure/nothrow. For example:
T abs(T num) pure nothrow {
return (num< 0) ? -1 * num
On Saturday 28 August 2010 18:29:02 dsimcha wrote:
> An issue that comes up very frequently when trying to use const, pure or
> nothrow in generic code is lack of knowledge of whether the functions
> you're calling are const/pure/nothrow. For example:
>
> T abs(T num) pure nothrow {
> return
An issue that comes up very frequently when trying to use const, pure or
nothrow in generic code is lack of knowledge of whether the functions you're
calling are const/pure/nothrow. For example:
T abs(T num) pure nothrow {
return (num < 0) ? -1 * num : num;
}
Looks pretty good. Won't work w
34 matches
Mail list logo
