gt; I think a simple way to do this with existing syntax is to add
> functionality for `module` to be used as a block.
>
>
> module modulename {
> void fun(){}
> }
> modulename.fun();
>
>
> An inline module.
You can always do something like declare a f
On Friday, 9 March 2018 at 18:51:50 UTC, Manu wrote:
If you tried to `import modulename;` from some other module...
how would the compiler know where to find it?
The compiler has to parse the module to find them correctly
already. When you do foo.bar into foo/bar.d, it is just the first
guess
ntax is to add functionality
>> for `module` to be used as a block.
>>
>>
>> module modulename {
>> void fun(){}
>> }
>> modulename.fun();
>>
>>
>> An inline module.
>
> If you tried to `import modulename;` from some other module... how
> would the compiler know where to find it?
me how to
> code.)
>
> I think a simple way to do this with existing syntax is to add functionality
> for `module` to be used as a block.
>
>
> module modulename {
> void fun(){}
> }
> modulename.fun();
>
>
> An inline module.
If you tri
o add
functionality for `module` to be used as a block.
module modulename {
void fun(){}
}
modulename.fun();
An inline module.
On 05.02.2018 16:27, H. S. Teoh wrote:
Apparently it's a prevailing style for Lisp and Lisp dialects like
Scheme. Random example (this is in Guile, a Scheme dialect, quoted from
open source code):
(define (match-predicate obj alist)
(if (null? alist)
"Unknown ty
On Mon, Feb 05, 2018 at 06:38:22PM +, Patrick Schluter via Digitalmars-d
wrote:
[...]
> When I programmed AutoLISP extension in AutoCAD I would use
> parentheses in the exact same way as I use { } in C. So not at the end
> of a line but vertically at the level of indentation;
>
> (defun x
On Monday, 5 February 2018 at 14:50:38 UTC, Steven Schveighoffer
wrote:
On 2/5/18 1:27 AM, H. S. Teoh wrote:
On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer
via Digitalmars-d wrote:
[...]
I don't have a hard time with braces. It tends to be worse
with
parentheses. Generally the
On Monday, 5 February 2018 at 15:27:56 UTC, H. S. Teoh wrote:
On Mon, Feb 05, 2018 at 09:50:38AM -0500, Steven Schveighoffer
via Digitalmars-d wrote:
On 2/5/18 1:27 AM, H. S. Teoh wrote:
> On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven
> Schveighoffer via Digitalmars-d wrote: [...]
> > I don'
On Mon, Feb 05, 2018 at 09:50:38AM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
> On 2/5/18 1:27 AM, H. S. Teoh wrote:
> > On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer via
> > Digitalmars-d wrote:
> > [...]
> > > I don't have a hard time with braces. It tends to be worse
On 2/5/18 1:27 AM, H. S. Teoh wrote:
On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
I don't have a hard time with braces. It tends to be worse with
parentheses. Generally these are indented properly, and not } all
on one line.
Wait till you
On 2/5/18 2:53 AM, Walter Bright wrote:
On 2/4/2018 11:34 AM, Steven Schveighoffer wrote:
On 2/2/18 7:10 PM, Walter Bright wrote:
On 2/1/2018 6:09 AM, Steven Schveighoffer wrote:
On 1/31/18 9:58 PM, Walter Bright wrote:
On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
Where it breaks down is
On 2/4/2018 11:34 AM, Steven Schveighoffer wrote:
On 2/2/18 7:10 PM, Walter Bright wrote:
On 2/1/2018 6:09 AM, Steven Schveighoffer wrote:
On 1/31/18 9:58 PM, Walter Bright wrote:
On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
Where it breaks down is when you have many nested tags, and you
On Monday, 5 February 2018 at 06:27:02 UTC, H. S. Teoh wrote:
On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer
via Digitalmars-d wrote: [...]
I don't have a hard time with braces. It tends to be worse
with parentheses. Generally these are indented properly, and
not } all on o
On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
[...]
> I don't have a hard time with braces. It tends to be worse with
> parentheses. Generally these are indented properly, and not } all
> on one line.
Wait till you see Lisp code. :-P
> Note: if the
On 2/2/18 7:10 PM, Walter Bright wrote:
On 2/1/2018 6:09 AM, Steven Schveighoffer wrote:
On 1/31/18 9:58 PM, Walter Bright wrote:
On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
Where it breaks down is when you have many nested tags, and you end
with )
Long ago, I adjusted my text edit
On Sat, Feb 03, 2018 at 06:25:26PM +, Adam D. Ruppe via Digitalmars-d wrote:
> On Saturday, 3 February 2018 at 17:20:35 UTC, H. S. Teoh wrote:
> > I got sick of just whining about, and decided to do something about
> > it instead:
>
> Whelp, g'luck. I've tried to null out the macro before, may
On Saturday, 3 February 2018 at 17:20:35 UTC, H. S. Teoh wrote:
I got sick of just whining about, and decided to do something
about it instead:
Whelp, g'luck. I've tried to null out the macro before, maybe
this approach will work better.
The stupid thing should just be killed entirely though
On Sat, Feb 03, 2018 at 06:18:55AM -0800, H. S. Teoh via Digitalmars-d wrote:
> On Sat, Feb 03, 2018 at 04:37:44AM +, Adam D. Ruppe via Digitalmars-d
> wrote:
> [...]
> > (note that the stupid leading _ is something I strip out too. Ddoc's
> > most moronic "feature". Can we PLEASE kill that?!?
On Saturday, 3 February 2018 at 11:41:27 UTC, Seb wrote:
I think that would only work if we drop the ddoc of phobos
entirely or add a similar feature to ddoc.
I could live with either :P
But the underscore thing is just plain bad. Literally NOBODY has
ever liked it - every time this comes up,
On Saturday, 3 February 2018 at 11:44:44 UTC, Seb wrote:
Have you thought of simply postprocessing REF_ALTTEXT for your
documentation engine for now?
It actually supports the macro, so I could just keep the upstream
source here, just the difference between them is kinda striking.
The history
On Sat, Feb 03, 2018 at 04:37:44AM +, Adam D. Ruppe via Digitalmars-d wrote:
[...]
> I'm updating my fork now and check out this merge conflict:
>
> <<< HEAD
> * source = The [isInputRange|input range] to encode.
> ===
> * source = The $(REF_ALTTEXT input range, isInputRang
On Saturday, 3 February 2018 at 04:37:44 UTC, Adam D. Ruppe wrote:
On Friday, 2 February 2018 at 20:15:11 UTC, H. S. Teoh wrote:
This is the kind of thing you should be promoting to Andrei to
convince him that dpldocs is better. ;-)
I'm updating my fork now and check out this merge conflict:
On Saturday, 3 February 2018 at 04:37:44 UTC, Adam D. Ruppe wrote:
On Friday, 2 February 2018 at 20:15:11 UTC, H. S. Teoh wrote:
This is the kind of thing you should be promoting to Andrei to
convince him that dpldocs is better. ;-)
I'm updating my fork now and check out this merge conflict:
On Friday, 2 February 2018 at 20:15:11 UTC, H. S. Teoh wrote:
This is the kind of thing you should be promoting to Andrei to
convince him that dpldocs is better. ;-)
I'm updating my fork now and check out this merge conflict:
<<< HEAD
* source = The [isInputRange|input range] to enco
On 2/1/2018 6:09 AM, Steven Schveighoffer wrote:
On 1/31/18 9:58 PM, Walter Bright wrote:
On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
Where it breaks down is when you have many nested tags, and you end with )
Long ago, I adjusted my text editor so that when the cursor is placed on )
On Friday, 2 February 2018 at 20:15:11 UTC, H. S. Teoh wrote:
This is the kind of thing you should be promoting to Andrei to
convince him that dpldocs is better. ;-)
I've laid out my arguments several times, including this point.
Actually, $(REF) was introduced after I made the argument, so it
On Fri, Feb 02, 2018 at 07:46:51PM +, Adam D. Ruppe via Digitalmars-d wrote:
> On Friday, 2 February 2018 at 18:45:50 UTC, H. S. Teoh wrote:
> > In an ideal world, you wouldn't need to encode any of this stuff
> > inside a ddoc comment.
>
> Well, that's what the Phobos REF macro does... sort o
On Friday, 2 February 2018 at 18:45:50 UTC, H. S. Teoh wrote:
In an ideal world, you wouldn't need to encode any of this
stuff inside a ddoc comment.
Well, that's what the Phobos REF macro does... sort of. You write
$(REF symbolName, std, module) and the macro figures out the
link. Though, ev
On Fri, Feb 02, 2018 at 10:49:18AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Friday, February 02, 2018 15:12:45 Adam D. Ruppe via Digitalmars-d wrote:
> > On Thursday, 1 February 2018 at 02:10:22 UTC, Jonathan M Davis
> > > IMHO, the main problem with ddoc for documentation is that it
On Friday, February 02, 2018 15:12:45 Adam D. Ruppe via Digitalmars-d wrote:
> On Thursday, 1 February 2018 at 02:10:22 UTC, Jonathan M Davis
> > IMHO, the main problem with ddoc for documentation is that it
> > doesn't automatically handle stuff like cross-links, and it
> > fundamentally can't, be
On Thursday, 1 February 2018 at 02:10:22 UTC, Jonathan M Davis
wrote:
Personally, I hate markdown, because it makes certain syntax
magical - e.g. it's not uncommon that a commit message ends up
looking bad when github uses it as the message for a PR,
because some piece of code contained * or so
On Thu, Feb 01, 2018 at 09:09:28AM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
> On 1/31/18 9:58 PM, Walter Bright wrote:
> > On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
> > > Where it breaks down is when you have many nested tags, and you
> > > end with )
> >
> > Long ago, I a
On 1/31/18 9:58 PM, Walter Bright wrote:
On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
Where it breaks down is when you have many nested tags, and you end
with )
Long ago, I adjusted my text editor so that when the cursor is placed on
), the matching ( is found. Ditto for { }, [ ], <
I can see that ddoc is a pretty hot topic here ;)
On Thursday, 1 February 2018 at 01:27:43 UTC, Adam D. Ruppe wrote:
To give you a quick answer, the tide is going toward ``. You
should probably just use it in most cases as long as the code
fits on a single line. If it is a multi-line sample, us
On Thursday, 1 February 2018 at 01:27:43 UTC, Adam D. Ruppe wrote:
On Wednesday, 31 January 2018 at 15:40:04 UTC, Jakub Łabaj
wrote:
What is the current state of the art of writing inline code in
the documentation?
To give you a quick answer, the tide is going toward ``. You
should probably
On Wednesday, January 31, 2018 18:58:29 Walter Bright via Digitalmars-d
wrote:
> On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
> > Where it breaks down is when you have many nested tags, and you end with
> > )
> Long ago, I adjusted my text editor so that when the cursor is placed on
> ),
On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
Where it breaks down is when you have many nested tags, and you end with )
Long ago, I adjusted my text editor so that when the cursor is placed on ), the
matching ( is found. Ditto for { }, [ ], < >, and #if/#elif/#else/#endif (!).
It's b
On Wednesday, January 31, 2018 16:19:53 H. S. Teoh via Digitalmars-d wrote:
> In general, almost all text macro / formatting systems, from LaTeX to
> HTML to ddoc, are universally ugly and verbose when it comes to tables,
> and makes my eyes bleed. The only exception I've found so far is
>
> markdo
On 1/31/18 5:55 PM, Adam D. Ruppe wrote:
Now though, inline code like $(D) and $(REF) are ambiguous. They are
short enough that they'd normally fall into my "ok with it" zone like
$(B)... but they are also so common and I want to encourage their use.
And having three shifted
On Wednesday, 31 January 2018 at 15:40:04 UTC, Jakub Łabaj wrote:
What is the current state of the art of writing inline code in
the documentation?
To give you a quick answer, the tide is going toward ``. You
should probably just use it in most cases as long as the code
fits on a single line
is in technical
docs, so it's not a biggie. And I do still prefer *...* over $(B ...).
I just don't like alphabetical macro names interspersed with text; it
makes it hard to parse the text with the eye.
> Now though, inline code like $(D) and $(REF) are ambiguous. They are
> s
to the *markdown way* in some
places, since at least the ddoc is deliberate. Only thing that
bugs me is when I try to write :) or 1) or similar in there but I
plan to fix that.
Now though, inline code like $(D) and $(REF) are ambiguous. They
are short enough that they'd normally fall into
On Wed, Jan 31, 2018 at 06:31:34PM +, Adam D. Ruppe via Digitalmars-d wrote:
> On Wednesday, 31 January 2018 at 17:14:56 UTC, H. S. Teoh wrote:
> > But otherwise, the two are equivalent. (In fact, backticks translate
> > directly into $(D ...) in the ddoc code. They are just syntactic
> > sugar
On Wednesday, 31 January 2018 at 17:14:56 UTC, H. S. Teoh wrote:
But otherwise, the two are
equivalent. (In fact, backticks translate directly into $(D
...) in the ddoc code. They are just syntactic sugar.)
No, they aren't. The `` is different in several ways including
doing character escapin
On Wed, Jan 31, 2018 at 03:40:04PM +, Jakub Łabaj via Digitalmars-d wrote:
> What is the current state of the art of writing inline code in the
> documentation?
>
> Wiki says "use `...` instead of $(D ...)":
> https://wiki.dlang.org/Contributing_to_Phobos#Docum
What is the current state of the art of writing inline code in
the documentation?
Wiki says "use `...` instead of $(D ...)":
https://wiki.dlang.org/Contributing_to_Phobos#Documentation_style.
Some arguments made here:
https://github.com/dlang/phobos/pull/5183#issuecomment-28189545
On Wednesday, 23 August 2017 at 09:12:19 UTC, Kagamin wrote:
On Tuesday, 22 August 2017 at 16:28:43 UTC, Moritz Maxeiner
wrote:
class Test
{
ubyte[] buf = new ubyte[1000]; // thread local storage,
instances in the same thread refer to the same static array
}
Dynamic initialization is don
On Tuesday, 22 August 2017 at 16:28:43 UTC, Moritz Maxeiner wrote:
class Test
{
ubyte[] buf = new ubyte[1000]; // thread local storage,
instances in the same thread refer to the same static array
}
Dynamic initialization is done by constructor:
class Test
{
static ubyte[1000] s;
On Tue, Aug 22, 2017 at 04:28:43PM +, Moritz Maxeiner via Digitalmars-d
wrote:
[...]
> I'd argue that - as new in this case doesn't allocate on the heap, but
> in the resulting application's appropriate segments) - it should work
> like this (from a language semantics standpoint):
>
> ---
>
On Tuesday, 22 August 2017 at 15:52:48 UTC, Kagamin wrote:
On Tuesday, 22 August 2017 at 14:53:21 UTC, Moritz Maxeiner
wrote:
There is a bug [1] - as others have pointed out - that the
static array isn't stored in TLS, but in global storage,
however, but that doesn't apply in this single thread
On Tuesday, 22 August 2017 at 14:53:21 UTC, Moritz Maxeiner wrote:
There is a bug [1] - as others have pointed out - that the
static array isn't stored in TLS, but in global storage,
however, but that doesn't apply in this single threaded case.
The initializer is copied from typeinfo, that can
On Tuesday, 22 August 2017 at 12:38:50 UTC, Jonas Mminnberg wrote:
On Tuesday, 22 August 2017 at 12:20:45 UTC, Moritz Maxeiner
wrote:
I agree that it can be confusing if you try to read it with
C++ semantics [1]; the solution, however, imho is not to
change D semantics or throw warnings [2]
On Tuesday, 22 August 2017 at 13:53:05 UTC, Daniel Kozak wrote:
s/buf/bug/
On Tue, Aug 22, 2017 at 3:52 PM, Daniel Kozak
wrote:
On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via
Digitalmars-d < digitalmars-d@puremagic.com> wrote:
On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnb
https://issues.dlang.org/show_bug.cgi?id=2947
s/buf/bug/
On Tue, Aug 22, 2017 at 3:52 PM, Daniel Kozak wrote:
> On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote:
>>
>>> ...
>>
>>
>> I agree that it can be confusin
On Tue, Aug 22, 2017 at 2:20 PM, Moritz Maxeiner via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote:
>
>> ...
>
>
> I agree that it can be confusing if you try to read it with C++ semantics
> [1]; the solution, however, imho
On 8/22/17 7:50 AM, Jonas Mminnberg wrote:
Because of D's static initialization of members, this assert fails:
class Test {
ubyte[] buf = new ubyte[1000];
}
void main() {
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
This is bad, since;
* It is
On Tuesday, 22 August 2017 at 12:20:45 UTC, Moritz Maxeiner wrote:
I agree that it can be confusing if you try to read it with C++
semantics [1]; the solution, however, imho is not to change D
semantics or throw warnings [2], but to refer to the D spec
[3], which states that static initializ
On Tuesday, 22 August 2017 at 11:50:50 UTC, Jonas Mminnberg wrote:
Because of D's static initialization of members, this assert
fails:
class Test {
ubyte[] buf = new ubyte[1000];
}
void main() {
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
This i
Because of D's static initialization of members, this assert
fails:
class Test {
ubyte[] buf = new ubyte[1000];
}
void main() {
auto a = new Test();
auto b = new Test();
assert(a.buf.ptr != b.buf.ptr);
}
This is bad, since;
* It is not how C++ works
* It introduces silent shari
On 2016-12-05 13:32, Ethan Watson wrote:
I also want to support statically sized
bit arrays, Phobos only provides support for dynamically sized.
That would be nice, I had a need for that.
--
/Jacob Carlborg
On Monday, 5 December 2016 at 11:57:18 UTC, Guillaume Chatelet
wrote:
Do you plan on contributing this back to phobos? I also came
across this exact same problem.
It'll want to go through a few polish iterations before I even
think of doing that; and it'll need support for things like
toStrin
On Friday, 2 December 2016 at 11:11:30 UTC, Ethan Watson wrote:
On Friday, 2 December 2016 at 10:16:17 UTC, Jacob Carlborg
wrote:
[...]
I was attempting to support all methods. new class isn't the
cleanest way of doing things either, so I decided I'd support
all the things and let the user c
On Friday, 2 December 2016 at 10:16:17 UTC, Jacob Carlborg wrote:
Using an alias without a template constraint works for me.
I was attempting to support all methods. new class isn't the
cleanest way of doing things either, so I decided I'd support all
the things and let the user choose what t
On 2016-12-02 10:11, Ethan Watson wrote:
On Friday, 2 December 2016 at 08:33:17 UTC, Jacob Carlborg wrote:
But wWhat about an anonymous class as ag0aep6g mentioned?
Usability I see is something that is key here. Having to do a typeof
yourself is one extra step away from an intuitive API.
So I
On Friday, 2 December 2016 at 08:33:17 UTC, Jacob Carlborg wrote:
But wWhat about an anonymous class as ag0aep6g mentioned?
Usability I see is something that is key here. Having to do a
typeof yourself is one extra step away from an intuitive API.
So I tried making a definition like this:
m
On 2016-12-01 21:31, Ethan Watson wrote:
https://github.com/Remedy-Entertainment/binderoo/blob/master/binderoo_client/d/src/binderoo/bitpacking.d
So I've been not-all-that-pleased with std.bitmanip.bitfields for a
while. It's nice that it's there, but I'm binding to C++ objects where
the meanin
On Thursday, 1 December 2016 at 20:31:32 UTC, Ethan Watson wrote:
https://github.com/Remedy-Entertainment/binderoo/blob/master/binderoo_client/d/src/binderoo/bitpacking.d
Stefan also reminded me that this would be a perfect spot where
__symbol CTFE variables would make life much easier (especi
On Thursday, 1 December 2016 at 20:58:53 UTC, H. S. Teoh wrote:
In cases like these, q{} comes to the rescue:
I had precisely zero idea this existed.
On Thu, Dec 01, 2016 at 08:31:32PM +, Ethan Watson via Digitalmars-d wrote:
[...]
> So the invokation, while not as readable, looks like:
>
> mixin BitPack!( "@PackSize( 3 ) int iSomeInt = 3; @PackSize( 1 ) bool
> bSomeBool = true; @PackSize( 4 ) int iSomeOtherInt;" );
>
> I'm sure I just mad
On Thursday, 1 December 2016 at 20:57:13 UTC, Andrei Alexandrescu
wrote:
The simplest way to go here is to accept an initializer for the
entire ubyte/ushort/uint/ulong underlying the bitfields. --
Andrei
In terms of efficiency at compile time, indeed. But there's
multiple paths there. You cou
On 12/01/2016 03:31 PM, Ethan Watson wrote:
I'm binding to C++ objects where the meaningful default values require
those packed values to have initial values. It's rather painful to get
that working with the Phobos implementation.
The simplest way to go here is to accept an initializer for the
On 12/01/2016 09:31 PM, Ethan Watson wrote:
I'm also sure there's plenty of other legit uses for inline aggregate
types. So while the feature doesn't exist in the language yet, at least
you can now see that there's quite a legit hacky-as-all-fuck workaround
for it.
Inter
while not as readable, looks like:
mixin BitPack!( "@PackSize( 3 ) int iSomeInt = 3; @PackSize( 1 )
bool bSomeBool = true; @PackSize( 4 ) int iSomeOtherInt;" );
I'm sure I just made someone cry looking at that.
I'm also sure there's plenty of other legit uses for inline
This *seems* to fix it:
https://github.com/D-Programming-Language/dmd/pull/5244
On Thursday, 29 October 2015 at 12:44:51 UTC, Cauterite wrote:
while working on issue 15235 I've been trying to add some new
tests for DMD.
will work pretty good as long as the code inside the string
literals are fairly short.
Another advantage would be that any specific compiler flags that are
required for a given test can be passed as a separate argument instead
of being inline in the source code as a comment.
--
/Jacob
On 10/29/2015 5:44 AM, Cauterite wrote:
while working on issue 15235 I've been trying to add some new tests for DMD.
The tests I want to write involve checking that certain asm statements throw
syntax errors instead of segfaults, but the fact that asmerr() ends compilation
unconditionally is pro
while working on issue 15235 I've been trying to add some new
tests for DMD.
The tests I want to write involve checking that certain asm
statements throw syntax errors instead of segfaults, but the fact
that asmerr() ends compilation unconditionally is proving to be a
problem. __traits(compil
state and always safe; for the cases
> >> where it's /undesirable/, there is noinline.
> >
> > No what I meant was when the compiler sees inline assembly or
> > anything else it deems not safe to inline, you can convice it
> > anyways. It is more like @trus
what I meant was when the compiler sees inline assembly or
> anything else it deems not safe to inline, you can convice it
> anyways. It is more like @trusted on otherwise @system
> functions. I just mentioned it so it is under consideration,
> as I have seen it in LLVM.
The problem wi
Am Sat, 26 Sep 2015 19:58:14 +0200
schrieb Artur Skawina via Digitalmars-d
:
> `allow` is the default state and always safe; for the cases
> where it's /undesirable/, there is noinline.
>
> artur
No what I meant was when the compiler sees inline assembly or
anything else it
Am Sat, 26 Sep 2015 21:11:07 +0200
schrieb Jacob Carlborg :
> On 2015-09-26 18:42, Marco Leise wrote:
>
> > Maybe the compiler devs can decide on more common syntax like
> > a generic core.attribute or just use pragma for inlining, but
> > extend it so that it offers more options:
>
> Yeah, we a
On 2015-09-26 18:42, Marco Leise wrote:
Maybe the compiler devs can decide on more common syntax like
a generic core.attribute or just use pragma for inlining, but
extend it so that it offers more options:
Yeah, we already have core.attribute. Now they just have to agree on the
name :)
--
/
ly since LDC/GDC have compiler-specific
> > > attributes that DMD doesn't recognise.
> >
> > I'm not sure how much this helps but can't you use a dummy UDA on
> > DMD for the GDC/LDC attributes?
>
> pragma(inline, true) void foo()
> @gcc.attribute.at
C/GDC have compiler-specific attributes
>>> that DMD doesn't recognise.
>>
>> I'm not sure how much this helps but can't you use a dummy UDA on DMD
>> for the GDC/LDC attributes?
>
> pragma(inline, true) void foo() @gcc.attribute.attrib
t;
> I'm not sure how much this helps but can't you use a dummy UDA on DMD
> for the GDC/LDC attributes?
pragma(inline, true) void foo() @gcc.attribute.attribute("forceinline")
@ldc.attribute.attribute("alwaysinline") @safe pure nothrow @nogc
{
// O
On 2015-09-26 06:27, Manu via Digitalmars-d wrote:
We _really_ need attribute aliasing in
some form, especially since LDC/GDC have compiler-specific attributes
that DMD doesn't recognise.
I'm not sure how much this helps but can't you use a dummy UDA on DMD
for the GDC/LDC attributes?
--
/J
ng, otherwise D wouldn't be so much
like C++ to begin with. __forceinline in C++ is exactly what people
want here. The behaviour is useful, and well understood; compiler will
always inline if possible, and warn if it can't. There's nothing wrong
with C++ in this case, and I wish D woul
On 24 Sep 2015 9:46 pm, "Walter Bright via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On 9/24/2015 8:47 AM, David Nadlinger wrote:
>>
>> What were the reasons behind this decision?
>
>
> The trouble is the compiler does inlining as a top dow
rong, otherwise D wouldn't be so much
> like C++ to begin with. __forceinline in C++ is exactly what people
> want here. The behaviour is useful, and well understood; compiler will
> always inline if possible, and warn if it can't. There's nothing wrong
> with C++ in
by decades of use
and millions of developers, remaining as people expect them to be...
then yes.
C++ didn't get *everything* wrong, otherwise D wouldn't be so much
like C++ to begin with. __forceinline in C++ is exactly what people
want here. The behaviour is useful, and well understood
looking into the remaining 2.068 test failures
>> for LDC, I was surprised to find out that DMD only honors pragma(inline,
>> true) when -inline is actually passed on the command line.
>>
>> This seems to be completely against what many people I spoke to
>> (inclu
On 9/24/2015 8:47 AM, David Nadlinger wrote:
What were the reasons behind this decision?
The trouble is the compiler does inlining as a top down traversal, whereas
forcing inline with no -inline would be a bottom up thing. The compiler could
always do the top down traversal, but it would
On Thursday, 24 September 2015 at 15:47:45 UTC, David Nadlinger
wrote:
which is to force inlining of certain functions even in debug
builds.
I don't understand what the problem is. Just pass -inline in your
debug build.
On Thursday, 24 September 2015 at 15:47:45 UTC, David Nadlinger
wrote:
Hi all,
I'm not even referring to the multitude of restrictions in the
DMD frontend inliner here. When looking into the remaining
2.068 test failures for LDC, I was surprised to find out that
DMD only honors pragma(i
Hi all,
I'm not even referring to the multitude of restrictions in the
DMD frontend inliner here. When looking into the remaining 2.068
test failures for LDC, I was surprised to find out that DMD only
honors pragma(inline, true) when -inline is actually passed on
the command line.
On Wed, 29 Jul 2015 18:35:36 +, David Nadlinger wrote:
> On Wednesday, 29 July 2015 at 04:26:36 UTC, ketmar wrote:
>> yet "that ship has sailed", i think.
>
> It hasn't yet. 2.068.0 will be the first release to include the pragma.
but one has to convince Walter, and it's not the easiest thin
"Steven Schveighoffer" wrote in message
news:mp86be$8f2$1...@digitalmars.com...
the only thing I can thing of is that true/false are (or have the
potential to be in this context) expressions, which means one could use
compile-time logic to specify inlining. The same wouldn't be true of
arbit
On Tuesday, 28 July 2015 at 22:12:21 UTC, David Nadlinger wrote:
I do think it is terribly confusing. pragma(inline) does not
cause any inlining by itself at all. It just means to let the
compiler do what it normally does (i.e. try to inline if
-inline is specified).
I suppose people were
1 - 100 of 302 matches
Mail list logo
