On Wednesday, 4 February 2015 at 21:05:59 UTC, Zach the Mystic
wrote:
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright
wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be support
On Thursday, 5 February 2015 at 14:43:40 UTC, Steven
Schveighoffer wrote:
On 2/4/15 1:46 AM, Zach the Mystic wrote:
It's a bikeshed argument, but why not:
pragma(inline, always); // warn if unable to inline
pragma(inline, never);
pragma(inline);// revert to default behavior
?
I k
On 2/4/15 1:46 AM, Zach the Mystic wrote:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler can
On 2/3/15 5:29 PM, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot inline it,
a warning will be generated. Implementations will like
On 2015-02-04 21:06, Walter Bright wrote:
With -inline:
pragma(inline, true) inlines
pragma(inline, false) does not inline
pragma(inline) inlines at compiler's discretion
Without -inline:
pragma(inline, true) inlines
pragma(inline, false) does not inline
pragma(i
On 2/4/2015 12:46 PM, Zach the Mystic wrote:
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's w
On 2/4/15 12:08 PM, Walter Bright wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear.
Please nail it down in t
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright
wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright
wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear
On Wednesday, 4 February 2015 at 20:09:04 UTC, Walter Bright
wrote:
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear
On 2/4/2015 10:00 AM, Jacob Carlborg wrote:
On 2015-02-03 23:29, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and move on.
This is affected by the -inline flag?
With -inline:
pragma(inline, true) inlines
pragma(inline, fal
On 2/4/2015 8:29 AM, Andrei Alexandrescu wrote:
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear.
Please nail it down in the doc so it doesn't get neglected. -- And
On Wednesday, 4 February 2015 at 18:00:19 UTC, Jacob Carlborg
wrote:
On 2015-02-03 23:29, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
This is affected by the -inline flag?
Interesting question. I'd say without -inlin
On 2015-02-03 23:29, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and move on.
This is affected by the -inline flag?
--
/Jacob Carlborg
On 2/4/15 4:08 AM, Walter Bright wrote:
On 2/4/2015 3:08 AM, Johannes Pfau wrote:
The compiler will still have to
generate a complete function which takes up space in the object
file.
Space in the object file is not important
Yah, just within reason etc. etc. -- Andrei
On 2/4/15 4:02 AM, Walter Bright wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear.
Please nail it down in the doc so it doesn't get neglected. -- Andrei
On Wednesday, 4 February 2015 at 12:02:32 UTC, Walter Bright
wrote:
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear.
As long as you're sure the pragma will never need more than three
values ([revert to
Am Wed, 04 Feb 2015 12:47:24 +
schrieb "Ola Fosheim Grøstad" :
> On Wednesday, 4 February 2015 at 10:57:25 UTC, Johannes Pfau
> wrote:
> > That's not necessary. For GDC you can do this:
> >
> > alias forceinline = Attribute!("forceinline");
> > (I don't remember the exact syntax but you can u
Am Wed, 04 Feb 2015 04:11:22 -0800
schrieb Walter Bright :
> On 2/4/2015 4:08 AM, Walter Bright wrote:
> > On 2/4/2015 3:08 AM, Johannes Pfau wrote:
> >> The compiler will still have to
> >> generate a complete function which takes up space in the object
> >> file.
> >
> > Space in the object file
On Wednesday, 4 February 2015 at 08:06:08 UTC, eles wrote:
On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:
On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote:
On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:
as for uglyness... it's too late to thing about
On Wednesday, 4 February 2015 at 10:57:25 UTC, Johannes Pfau
wrote:
That's not necessary. For GDC you can do this:
alias forceinline = Attribute!("forceinline");
(I don't remember the exact syntax but you can use an alias)
Then you can simply do
@forceinline void test (){};
Yes, your attribut
On 2/4/2015 4:08 AM, Walter Bright wrote:
On 2/4/2015 3:08 AM, Johannes Pfau wrote:
The compiler will still have to
generate a complete function which takes up space in the object
file.
Space in the object file is not important, space in the executable is. It's the
linker's job to remove unref
On 2/4/2015 3:08 AM, Johannes Pfau wrote:
The compiler will still have to
generate a complete function which takes up space in the object
file.
Space in the object file is not important, space in the executable is. It's the
linker's job to remove unreferenced functions (dmd places each functio
On 2/4/2015 1:39 AM, ponce wrote:
Would pragma(inline, ) be supported though?
Yes. That's what I intended, sorry the wording wasn't clear.
On Wednesday, 4 February 2015 at 09:39:56 UTC, ponce wrote:
Would pragma(inline, ) be supported though? This
would allow to pass inlining as a template parameter (can be
useful to force recursive inlining, or to force inlining
depending on the call point).
Nice idea.
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
Great, gets the job done and you even thought of on/off/default
to apply this to multiple functions.
It provides the common inlin
Am Tue, 03 Feb 2015 14:29:59 -0800
schrieb Walter Bright :
> http://wiki.dlang.org/DIP56
>
> There's been enough discussion, time to make a decision and move on.
>
> I changed the description to:
>
> "If a pragma specifies always inline, and the compiler cannot inline
> it, a warning will be ge
On Wednesday, 4 February 2015 at 10:57:25 UTC, Johannes Pfau
wrote:
alias forceinline = Attribute!("forceinline");
(I don't remember the exact syntax but you can use an alias)
The syntax I'm using is...
version (GNU)
{
static import gcc.attribute;
enum inline = gcc.attribute.attribute(
Am Wed, 04 Feb 2015 06:59:52 +
schrieb "Ola Fosheim Grøstad" :
> but I agree that the pragma syntax is ugly, but "@attribute" is
> also ugly.
>
> Maybe better to reserve "@_word" so that they cannot be used for
> UDA and let all pragmas start with "@_":
That's not necessary. For GDC you ca
On 04.02.15 07:46, Zach the Mystic wrote:
It's a bikeshed argument, but why not:
pragma(inline, always); // warn if unable to inline
pragma(inline, never);
pragma(inline);// revert to default behavior
...?
I know `true` and `false` are keywords, but why confuse people? What is
a "tru
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Wednesday, February 04, 2015 09:07:12 ketmar via Digitalmars-d wrote:
> D is in the same position now. "that ship is sailed", "we don't break the
> code", "happy legacy, folks!"
Not quite. The C++ folks basically won't break backwards compatibility for
anything. There are a few rare cases in th
On Wed, 04 Feb 2015 08:11:40 +, Iain Buclaw via Digitalmars-d wrote:
> You can tell the compiler to ignore unknown pragmas too...
`@attribute("...")` has another advantage: it's already working at least
in one compiler. whereas proposed `pragma` is not working yet. ;-)
signature.asc
Descrip
On Wed, 04 Feb 2015 08:06:06 +, eles wrote:
> On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:
>> On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote:
>>
>>> On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:
>
>> as for uglyness... it's too late to thing ab
On 4 February 2015 at 07:16, ketmar via Digitalmars-d
wrote:
> On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote:
>
>> On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:
>>> there. i still can't see what's wrong with `@attribute("inline")`,
>>> `@attribute("force_inline")` an
On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:
On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote:
On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:
as for uglyness... it's too late to thing about this. one more,
one
less... ;-)
Wait... That used to be
On Wed, 04 Feb 2015 07:26:04 +, Ola Fosheim Grøstad wrote:
> On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:
>> as for uglyness... it's too late to thing about this. one more,
>> one less... ;-)
>
> Are you following the reasoning: the uglier the better, because that
> will set
On Wednesday, 4 February 2015 at 07:16:03 UTC, ketmar wrote:
as for uglyness... it's too late to thing about this. one more,
one less... ;-)
Are you following the reasoning: the uglier the better, because
that will set us up for a clean slate syntax redesign? :)
On Wed, 04 Feb 2015 06:59:52 +, Ola Fosheim Grøstad wrote:
> On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:
>> there. i still can't see what's wrong with `@attribute("inline")`,
>> `@attribute("force_inline")` and so on. ah, except it breaks one of the
>> first rules in The Book
On Wednesday, 4 February 2015 at 05:20:30 UTC, ketmar wrote:
there. i still can't see what's wrong with
`@attribute("inline")`,
`@attribute("force_inline")` and so on. ah, except it breaks
one of the
first rules in The Book Of D: "try to escape uniformity
whenever it is possible".
Using pragm
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Wed, 04 Feb 2015 05:24:18 +, Orvid King wrote:
> Yes, but @attribute isn't defined when compiling with DMD, resulting in
> the need for some fun with version statements.
exactly one module, say, for example, `gcccompat.d`:
module gcccompat;
version(GNU) {
public import gcc.attribu
On Tue, 03 Feb 2015 23:37:58 +, Justin Whear wrote:
> On Tue, 03 Feb 2015 23:34:15 +, an wrote:
>
>> Pragmas can be used as attribute that doesn't affect the semantics.
>> This syntax is not supported in this DIP?
>>
>> pragma(inline, true)
>> {
>> void foo() { }
>> void bar() { }
>> }
>
On Wednesday, 4 February 2015 at 05:17:11 UTC, ketmar wrote:
On Tue, 03 Feb 2015 22:47:30 +, Orvid King wrote:
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright
wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed th
On Tue, 03 Feb 2015 22:47:30 +, Orvid King wrote:
> On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
>> http://wiki.dlang.org/DIP56
>>
>> There's been enough discussion, time to make a decision and move on.
>>
>> I changed the description to:
>>
>> "If a pragma specifies alway
On Wednesday, 4 February 2015 at 04:46:41 UTC, Walter Bright
wrote:
The pragma will cause it to ignore the cost function and always
inline it.
So, if pragma(inline, true) ignores the cost function, will it
*always* inline it, or always apply the -inline compiler flag
rules (whatever they ar
On 2/3/2015 9:00 PM, Mike wrote:
On Wednesday, 4 February 2015 at 04:46:41 UTC, Walter Bright wrote:
The pragma will cause it to ignore the cost function and always inline it.
So, if pragma(inline, true) ignores the cost function, will it *always* inline
it, or always apply the -inline compil
On Wednesday, 4 February 2015 at 05:03:03 UTC, Walter Bright
wrote:
So, if pragma(inline, true) ignores the cost function, will it
*always* inline
it, or always apply the -inline compiler flag rules (whatever
they are)?
If the former,
Yes.
Ok, then please ignore all my posts on this top
On 2/3/2015 5:57 PM, ZombineDev wrote:
Will this proposal allow to override the inlining of a function at the call
site?
No. It marks the function, not the call site.
Though there would a simple way to do this - make a 'never inline' function that
wraps the 'always inline' one, and call the
On 2/3/2015 4:24 PM, Mike wrote:
...it should read...
pragma(inline, true); // enable -inline compiler flag
pragma(inline, false); // disable -inline compiler flag
pragma(inline);// use whatever is passed in on the command line
...as that is really the intent of DIP56 as confirmed by W
On Wednesday, 4 February 2015 at 04:11:39 UTC, Mike wrote:
On Wednesday, 4 February 2015 at 03:59:08 UTC, Meta wrote:
pragma(inline, true) will not compile if you enabled warnings
as errors.
I know, but this is the mediocrity I'm talking about: it only
works as one wishes/expects under cer
On Wednesday, 4 February 2015 at 03:59:08 UTC, Meta wrote:
pragma(inline, true) will not compile if you enabled warnings
as errors.
I know, but this is the mediocrity I'm talking about: it only
works as one wishes/expects under certain conditions.
Mike
On Wednesday, 4 February 2015 at 02:44:46 UTC, Mike wrote:
This is not what I want either. I find @always_inline and
@never_inline attributes with compile-time enforcement *far*
more useful.
pragma(inline, true) will not compile if you enabled warnings as
errors.
On Wednesday, 4 February 2015 at 02:52:07 UTC, Andrei
Alexandrescu wrote:
The question is, can you get work done with the currently
proposed semantics? If so, let's commit to this and move on.
Yes, I may be able to make use of it on occasion, but only
because other, more useful features ar
On 2/3/15 6:44 PM, Mike wrote:
On Wednesday, 4 February 2015 at 00:39:05 UTC, Dicebot wrote:
pragma(inline, true); // enable -inline compiler flag
pragma(inline, false); // disable -inline compiler flag
pragma(inline);// use whatever is passed in on the command line
...as that is real
On Wednesday, 4 February 2015 at 00:39:05 UTC, Dicebot wrote:
pragma(inline, true); // enable -inline compiler flag
pragma(inline, false); // disable -inline compiler flag
pragma(inline);// use whatever is passed in on the
command line
...as that is really the intent of DIP56 as conf
Will this proposal allow to override the inlining of a function
at the call site?
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Wednesday, 4 February 2015 at 00:24:25 UTC, Mike wrote:
I think this whole debate could have been avoided if the DIP
was worded differently.
Instead of...
pragma(inline, true); // always inline
pragma(inline, false); // never inline
pragma(inline);// revert to default behavior
...
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On 2/3/2015 2:47 PM, Orvid King wrote:
I just created a proposal for a more general syntax to allow user's to apply
attributes like inlining in a way that can easily be supported across compilers,
and, in my eyes, is clearer about what code the attribute is applied to than a
pragma is.
http://wi
On Tue, 03 Feb 2015 23:34:15 +, an wrote:
> Pragmas can be used as attribute that doesn't affect the semantics. This
> syntax is not supported in this DIP?
>
> pragma(inline, true)
> {
> void foo() { }
> void bar() { }
> }
I assume it's covered by "If this pragma is outside of a function, it
On Tuesday, 3 February 2015 at 23:25:26 UTC, Peter Alexander
wrote:
On Tuesday, 3 February 2015 at 23:23:35 UTC, deadalnix wrote:
We have an attribute system, why make this a pragma ?
Rationale is in the DIP: "These are not attributes because they
should not affect the semantics of the functi
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Tuesday, 3 February 2015 at 23:23:35 UTC, deadalnix wrote:
We have an attribute system, why make this a pragma ?
Rationale is in the DIP: "These are not attributes because they
should not affect the semantics of the function. In particular,
the function signature must not be affected."
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and
move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot
inline it, a warning will be generat
On Tuesday, 3 February 2015 at 22:30:22 UTC, Walter Bright wrote:
There's been enough discussion, time to make a decision and
move on.
I'm glad this is being said more and more around these parts.
Some stuff just seems to be stagnating forever.
http://wiki.dlang.org/DIP56
There's been enough discussion, time to make a decision and move on.
I changed the description to:
"If a pragma specifies always inline, and the compiler cannot inline it, a
warning will be generated. Implementations will likely vary in their ability to
inline."
69 matches
Mail list logo
