On Thursday, 15 December 2022 at 20:12:12 UTC, Ali Çehreli wrote:
I think this is a bug because the documentation clearly talks
about destroying the object:
OK: https://github.com/dlang/phobos/pull/8651
> do we need to do some kind of deprecation?
The behavior is so different from the
On 12/15/22 11:31, Nick Treleaven wrote:
> On Wednesday, 14 December 2022 at 17:41:07 UTC, Ali Çehreli wrote:
>> I've never used Unique but I think it has a bug (or a design issue?):
>> Its destructor is the following:
>>
>> ~this()
>> {
>> if (_p !is null)
>> {
>>
On Friday, 22 July 2022 at 12:33:37 UTC, Anthony Quizon wrote:
I get:
```
foo.d(16): Error: mixin `foo.B.opBi!(B, ["+":function (B a, B
b) pure nothrow @nogc @safe => a])` does not match template
declaration `opBi(A, A function(A, A)[string] f0)`
```
Is this a bug or am I doing something
On Friday, 22 July 2022 at 12:56:44 UTC, Adam D Ruppe wrote:
```
mixin template opBi(
alias f0
) {
static foreach (k, f; f0) { typeof(this) opBinary(string op:
k)(typeof(this) r) { return f(this, r); } }
}
```
Thanks, this seems to do the trick.
On 7/22/22 8:33 AM, Anthony Quizon wrote:
Hello,
I'm trying to create a mixin for quick binary operator overloads by
passing in types with a corresponding associative array of strings to
functions. However,
the code I currently have:
```
module foo;
mixin template opBi(
A, A
On Friday, 22 July 2022 at 12:33:37 UTC, Anthony Quizon wrote:
Is this a bug or am I doing something wrong?
I think this is a bug. The compiler must not take well to this
pattern, maybe the assoc array template argument, but idk. It
looks like the first type used gets cached and reused even
On Saturday, 18 December 2021 at 12:50:17 UTC, Tejas wrote:
As Ali said, this is an implementation issue.
So I guess the answer to your question is that this is a bug.
Please file a report at [issues.dlang.org](issues.dlang.org)
Looks like this is same case:
On Saturday, 18 December 2021 at 11:01:53 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 19:03:05 UTC, Tejas wrote:
Well, I got completely mislead by my experiment
```d
struct S
{
~this() immutable {}
}
```
Interesting what discussed behaviour isn't affects method what
On Friday, 17 December 2021 at 19:03:05 UTC, Tejas wrote:
Well, I got completely mislead by my experiment
```d
struct S
{
~this() immutable {}
}
```
Interesting what discussed behaviour isn't affects method what
implements same functionality as dtor and called explictly at
each
On Friday, 17 December 2021 at 18:51:56 UTC, Ali Çehreli wrote:
On 12/17/21 10:01 AM, Tejas wrote:
> [...]
Storage,
There is no such requirement nor guarantee.
[...]
Well, I got completely mislead by my experiment
```d
struct S
{
~this() immutable {}
}
void main()
{
immutable S
On 12/17/21 10:01 AM, Tejas wrote:
> I think since `immutable` objects are kept in Read Only Storage,
There is no such requirement nor guarantee.
> you
> can't call destructors on them
Destructor is nothing but a piece of code that is executed when an
object's life ends. A destructor need
On Friday, 17 December 2021 at 18:32:43 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 18:02:52 UTC, Tejas wrote:
I improved your sample:
```d
immutable struct S
{
~this() {}
}
immutable struct S2
{
S sss;
~this() {}
}
void main()
{
S2 s = S2();
}
```
```
Error:
On Friday, 17 December 2021 at 18:02:52 UTC, Tejas wrote:
I improved your sample:
```d
immutable struct S
{
~this() {}
}
immutable struct S2
{
S sss;
~this() {}
}
void main()
{
S2 s = S2();
}
```
```
Error: `immutable` method `serializer_bug.S.~this` is not
callable using a
On Friday, 17 December 2021 at 18:19:34 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 18:01:03 UTC, Tejas wrote:
I think since `immutable` objects are kept in Read Only Storage
Some of them can be stored in ROM in some cases, but actually
"immutable" keyword means "not mutable
On Friday, 17 December 2021 at 18:01:03 UTC, Tejas wrote:
I think since `immutable` objects are kept in Read Only Storage
Some of them can be stored in ROM in some cases, but actually
"immutable" keyword means "not mutable for whole its lifetime"
On Friday, 17 December 2021 at 18:01:03 UTC, Tejas wrote:
On Friday, 17 December 2021 at 17:34:05 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 17:27:53 UTC, Denis Feklushkin
wrote:
[...]
("serializer_bug" is just name of my local .d file)
I think since `immutable`
On Friday, 17 December 2021 at 17:34:05 UTC, Denis Feklushkin
wrote:
On Friday, 17 December 2021 at 17:27:53 UTC, Denis Feklushkin
wrote:
~this() {} // Comment out this to fix this compilation
error:
// Error: `immutable` method `serializer_bug.Imm.~this` is
("serializer_bug" is
On Friday, 17 December 2021 at 17:27:53 UTC, Denis Feklushkin
wrote:
~this() {} // Comment out this to fix this compilation
error:
// Error: `immutable` method `serializer_bug.Imm.~this` is
("serializer_bug" is just name of my local .d file)
On Sunday, 24 October 2021 at 14:38:44 UTC, jfondren wrote:
With nothing to the contrary, I'd take "must be terminated by a
null pointer" as "can't itself be a null pointer".
The execve(2) is more explicit:
"The argument argv is a pointer to a null-terminated array of
character pointers
On Sunday, 24 October 2021 at 14:38:44 UTC, jfondren wrote:
[...]
With nothing to the contrary, I'd take "must be terminated by a
null pointer" as "can't itself be a null pointer".
ah yeah, and thanks, of course ... how would the count of arg be
known without the sentinel...
On Sunday, 24 October 2021 at 14:21:52 UTC, Basile B. wrote:
What do you think ?
I'm very surprised that this is even allowed. Apparently it's
Linux userspace that normally complains about it:
https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/progname.c#n54
The manpages just say
```
On Sunday, 24 October 2021 at 14:21:52 UTC, Basile B. wrote:
The following code, on linux
[...]
What do you think ?
Forgot to say that this change
```diff
- execv("a", null);
+ execv("a", ["whatever".ptr].ptr);
```
makes the problem goes away, so it would be caused by how `null`
args are
On Wednesday, 7 April 2021 at 17:31:09 UTC, Paul Backus wrote:
On Wednesday, 7 April 2021 at 17:04:56 UTC, novice2 wrote:
On Wednesday, 7 April 2021 at 13:43:18 UTC, Paul Backus wrote:
So, you should change your code to
writefln("%-(%s, %)", s);
sorry i dont read docs so carefully
On Wednesday, 7 April 2021 at 17:31:09 UTC, Paul Backus wrote:
It's not your fault--this is a pretty obscure feature, and it's
not documented very well. Even after you've found the correct
page in the documentation (the page for `formattedWrite` [1]),
you have to scroll down past multiple
On 4/7/21 10:04 AM, novice2 wrote:
On Wednesday, 7 April 2021 at 13:43:18 UTC, Paul Backus wrote:
So, you should change your code to
writefln("%-(%s, %)", s);
sorry i dont read docs so carefully
thanks
For the sake of completeness, I mention this feature in a couple of
other places:
On Wednesday, 7 April 2021 at 17:04:56 UTC, novice2 wrote:
On Wednesday, 7 April 2021 at 13:43:18 UTC, Paul Backus wrote:
So, you should change your code to
writefln("%-(%s, %)", s);
sorry i dont read docs so carefully
thanks
It's not your fault--this is a pretty obscure feature, and
On Wednesday, 7 April 2021 at 13:43:18 UTC, Paul Backus wrote:
So, you should change your code to
writefln("%-(%s, %)", s);
sorry i dont read docs so carefully
thanks
On Wednesday, 7 April 2021 at 13:31:59 UTC, novice3 wrote:
there is extra quotes, wich not present in firmat specifier.
is this bug, or i should change something in my code?
This is actually an intentional feature (albeit kind of a stupid
one). From the documentation:
Inside a compound
On Saturday, 17 August 2019 at 12:04:46 UTC, Mike Parker wrote:
Thanks to BOS Platform Korea, the new Bug Bounty system is
live. Anyone willing to seed new bounties or increase the
existing ones is free to do so. We hope to see the number of
bounties grow and a few folks make some money from
On Friday, 14 June 2019 at 05:35:05 UTC, Amex wrote:
I used it to avoid having to write bar twice or use a flag but
it's not working... I see no reason why it should not work.
scope(exit) is suppose to execute the block at the end of the
function call, right?
No, a scope guard executes at
On Saturday, 30 March 2019 at 00:44:31 UTC, Alex wrote:
On Saturday, 30 March 2019 at 00:06:23 UTC, H. S. Teoh wrote:
On Fri, Mar 29, 2019 at 11:44:35PM +, Alex via
Digitalmars-d-learn wrote:
interface iBase
{
iBase fooBase(iBase);
}
class cBase : iBase
{
cBase
On Saturday, 30 March 2019 at 00:06:23 UTC, H. S. Teoh wrote:
On Fri, Mar 29, 2019 at 11:44:35PM +, Alex via
Digitalmars-d-learn wrote:
interface iBase
{
iBase fooBase(iBase);
}
class cBase : iBase
{
cBase fooBase(cBase c) { return c; }
}
cBase.fooBase should be a valid
On Fri, Mar 29, 2019 at 11:44:35PM +, Alex via Digitalmars-d-learn wrote:
> interface iBase
> {
> iBase fooBase(iBase);
> }
>
>
> class cBase : iBase
> {
> cBase fooBase(cBase c) { return c; }
>
> }
>
> cBase.fooBase should be a valid override of iBase.fooBase because they
On Friday, 29 March 2019 at 23:44:35 UTC, Alex wrote:
> interface iBase
> {
> iBase fooBase(iBase);
> }
>
>
> class cBase : iBase
> {
> cBase fooBase(cBase c) { return c; }
>
> }
>
> cBase.fooBase should be a valid override of iBase.fooBase
> because
> they are the same type!
On 02/19/2019 03:21 PM, SrMordred wrote:
> On Tuesday, 19 February 2019 at 23:03:37 UTC, Paul Backus wrote:
>> Inside a templated struct, the name of the template, by itself,
>> actually refers to the current instantiation. So when you write `Test`
>> in your __traits(isSame) test, the compiler
On Tuesday, 19 February 2019 at 23:03:37 UTC, Paul Backus wrote:
On Tuesday, 19 February 2019 at 22:43:25 UTC, SrMordred wrote:
import std.traits;
import std.stdio;
struct Test(T)
{
this(T)( auto ref T value )
{
writeln( TemplateOf!(typeof(value)).stringof);
On Tuesday, 19 February 2019 at 22:43:25 UTC, SrMordred wrote:
import std.traits;
import std.stdio;
struct Test(T)
{
this(T)( auto ref T value )
{
writeln( TemplateOf!(typeof(value)).stringof);
writeln( __traits(isSame, TemplateOf!(typeof(value)), Test)
);
On Fri, Feb 08, 2019 at 11:36:03PM +, JN via Digitalmars-d-learn wrote:
> On Friday, 8 February 2019 at 23:30:44 UTC, H. S. Teoh wrote:
[...]
> > Pity we couldn't get rid of std.stdio.
[...]
> I can replace it with core.stdc.stdio if it's any better. Looks like
> any attempt to do a check for
On Friday, 8 February 2019 at 23:30:44 UTC, H. S. Teoh wrote:
On Fri, Feb 08, 2019 at 10:45:39PM +, JN via
Digitalmars-d-learn wrote: [...]
Anyway, I reduced the code further manually. It's very hard to
reduce it any further. For example, removing the assignments
in fromEulerAngles static
On Fri, Feb 08, 2019 at 10:45:39PM +, JN via Digitalmars-d-learn wrote:
[...]
> Anyway, I reduced the code further manually. It's very hard to reduce
> it any further. For example, removing the assignments in
> fromEulerAngles static method hides the bug. Likewise, replacing
> writeln with
On Friday, 8 February 2019 at 22:11:31 UTC, H. S. Teoh wrote:
Pity I still can't reproduce the problem locally. Otherwise I
would reduce it even more -- e.g., eliminate std.stdio
dependency and have the program fail on assert(obj != null),
and a bunch of other things to make it easier for
On Fri, Feb 08, 2019 at 09:42:11PM +, JN via Digitalmars-d-learn wrote:
> On Friday, 8 February 2019 at 21:35:34 UTC, H. S. Teoh wrote:
> > On Fri, Feb 08, 2019 at 09:23:40PM +, JN via Digitalmars-d-learn
> > wrote: [...]
> > > I managed to greatly reduce the source code. I have filed a
On Friday, 8 February 2019 at 21:35:34 UTC, H. S. Teoh wrote:
On Fri, Feb 08, 2019 at 09:23:40PM +, JN via
Digitalmars-d-learn wrote: [...]
I managed to greatly reduce the source code. I have filed a
bug with the reduced testcase
https://issues.dlang.org/show_bug.cgi?id=19662 .
Haha, you
On Fri, Feb 08, 2019 at 09:23:40PM +, JN via Digitalmars-d-learn wrote:
[...]
> I managed to greatly reduce the source code. I have filed a bug with
> the reduced testcase https://issues.dlang.org/show_bug.cgi?id=19662 .
Haha, you were right! It's a compiler bug, another one of those nasty
On Friday, 8 February 2019 at 09:30:12 UTC, Vladimir Panteleev
wrote:
On Friday, 8 February 2019 at 09:28:48 UTC, JN wrote:
I will try. However, one last thing - in the example test
scripts, it runs first with one compiler setting (or D
version) and the second time with the other compiler
On Friday, 8 February 2019 at 09:28:48 UTC, JN wrote:
I will try. However, one last thing - in the example test
scripts, it runs first with one compiler setting (or D version)
and the second time with the other compiler setting (or D
version). But it looks like the exit code of the first run
On Friday, 8 February 2019 at 07:30:41 UTC, Vladimir Panteleev
wrote:
On Thursday, 7 February 2019 at 22:16:19 UTC, JN wrote:
Does it also work for dub projects?
It will work if you can put all the relevant D code in one
directory, which is harder for Dub, as it likes to pull
dependencies
On Thursday, 7 February 2019 at 22:16:19 UTC, JN wrote:
Does it also work for dub projects?
It will work if you can put all the relevant D code in one
directory, which is harder for Dub, as it likes to pull
dependencies from all over the place. When "dub dustmite" is
insufficient (as in
On Thu, Feb 07, 2019 at 10:16:19PM +, JN via Digitalmars-d-learn wrote:
[...]
> Anyway, I managed to reduce the source code greatly manually:
>
> https://github.com/helikopterodaktyl/repro_d_release/
>
> unfortunately I can't get rid of the dlib dependency. When built with
> debug, test
On Thursday, 7 February 2019 at 03:50:32 UTC, Vladimir Panteleev
wrote:
On Monday, 17 December 2018 at 21:59:59 UTC, JN wrote:
while working on my game engine project, I encountered a DMD
codegen bug. It occurs only when compiling in release mode,
debug works.
Old thread, but FWIW, such bugs
On Monday, 17 December 2018 at 21:59:59 UTC, JN wrote:
while working on my game engine project, I encountered a DMD
codegen bug. It occurs only when compiling in release mode,
debug works.
Old thread, but FWIW, such bugs can be easily and precisely
reduced with DustMite. In your test script,
On Wed, Feb 06, 2019 at 10:37:27PM +, JN via Digitalmars-d-learn wrote:
[...]
> I am not sure if it's a pointer bug. What worries me is that it breaks
> at the start of the program, but uncommenting code at the end of the
> program influences it. Unless there's some crazy reordering going on,
On Wednesday, 6 February 2019 at 22:22:26 UTC, H. S. Teoh wrote:
Of course, I've no clue whether this is the cause of your
problems -- it's just one of many possibilities. Pointer bugs
are nasty things to debug, regardless of whether or not they've
been abstracted away in nicer clothing. I
On Wed, Feb 06, 2019 at 09:50:44PM +, JN via Digitalmars-d-learn wrote:
> On Tuesday, 18 December 2018 at 22:56:19 UTC, H. S. Teoh wrote:
> > Since no explicit slicing was done, there was no compiler error /
> > warning of any sort, and it wasn't obvious from the code what had
> > happened. By
On Tuesday, 18 December 2018 at 22:56:19 UTC, H. S. Teoh wrote:
Since no explicit slicing was done, there was no compiler error
/ warning of any sort, and it wasn't obvious from the code what
had happened. By the time doSomething() was called, it was
already long past the source of the problem
On Tue, Dec 18, 2018 at 10:29:07PM +, JN via Digitalmars-d-learn wrote:
> On Monday, 17 December 2018 at 22:22:05 UTC, H. S. Teoh wrote:
> > A less likely possibility might be an optimizer bug -- do you get
> > different results if you add / remove '-O' (and/or '-inline') from
> > your dmd
On Monday, 17 December 2018 at 22:22:05 UTC, H. S. Teoh wrote:
A less likely possibility might be an optimizer bug -- do you
get different results if you add / remove '-O' (and/or
'-inline') from your dmd command-line? If some combination of
-O and -inline (or their removal thereof) "fixes"
On Monday, 17 December 2018 at 21:59:59 UTC, JN wrote:
Hey guys,
while working on my game engine project, I encountered a DMD
codegen bug. It occurs only when compiling in release mode,
debug works. Unfortunately I am unable to minimize the code,
since it's quite a bit of code, and changing
On Mon, Dec 17, 2018 at 09:59:59PM +, JN via Digitalmars-d-learn wrote:
[...]
> class Texture2D {}
>
> auto a = new Texture2D();
> auto b = new Texture2D();
> auto c = new Texture2D();
> Texture2D[int] TextureBindings;
> writeln(a, b, c);
> textureBindings[0] = a;
> textureBindings[1] = b;
>
On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler
wrote:
For example, the "Conditional operator" in D actually has a
higher priority than an assignment, but in C++ it's the same
and is evaluated right-to-left. So this expression would be
different in C++ and D:
a ? b : c = d
In
On Friday, 12 October 2018 at 13:15:22 UTC, Steven Schveighoffer
wrote:
On 10/12/18 6:06 AM, Kagamin wrote:
On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler
wrote:
[...]
That's https://issues.dlang.org/show_bug.cgi?id=14186
Wow, interesting that C precedence is different from
On Thursday, 11 October 2018 at 23:17:57 UTC, Jonathan M Davis
wrote:
On Thursday, October 11, 2018 8:35:34 AM MDT James Japherson
via Digitalmars-d wrote:
Certainly, major languages like C, C++, Java, and C# all do it
the way that D does, and they all have the same kind of
precedence for
On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler
wrote:
On Thursday, 11 October 2018 at 21:57:00 UTC, Jonathan M Davis
wrote:
On Thursday, October 11, 2018 1:09:14 PM MDT Jonathan Marler
via Digitalmars-d wrote:
On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson
wrote:
On 10/12/18 6:06 AM, Kagamin wrote:
On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler wrote:
I had a look at the table again, looks like the ternary operator is on
there, just called the "conditional operator". And to clarify, D's
operator precedence is close to C/C++ but doesn't
On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler
wrote:
I had a look at the table again, looks like the ternary
operator is on there, just called the "conditional operator".
And to clarify, D's operator precedence is close to C/C++ but
doesn't match exactly. This is likely a
On 10/11/18 9:16 PM, Jonathan Marler wrote:
On Thursday, 11 October 2018 at 23:29:05 UTC, Steven Schveighoffer wrote:
On 10/11/18 7:17 PM, Jonathan Marler wrote:
I had a look at the table again, looks like the ternary operator is
on there, just called the "conditional operator". And to
On Thursday, 11 October 2018 at 23:29:05 UTC, Steven
Schveighoffer wrote:
On 10/11/18 7:17 PM, Jonathan Marler wrote:
I had a look at the table again, looks like the ternary
operator is on there, just called the "conditional operator".
And to clarify, D's operator precedence is close to
On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson
wrote:
Took me about an hour to track this one down!
A + (B == 0) ? 0 : C;
D is evaluating it as
(A + (B == 0)) ? 0 : C;
That's why shouldn't compose it like that.
It's been a constant source of bugs in C/C++ code:
On 10/11/18 7:17 PM, Jonathan Marler wrote:
I had a look at the table again, looks like the ternary operator is on
there, just called the "conditional operator". And to clarify, D's
operator precedence is close to C/C++ but doesn't match exactly. This
is likely a result of the grammar
On Thursday, 11 October 2018 at 21:57:00 UTC, Jonathan M Davis
wrote:
On Thursday, October 11, 2018 1:09:14 PM MDT Jonathan Marler
via Digitalmars-d wrote:
On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson
wrote:
> Took me about an hour to track this one down!
>
> A + (B == 0) ? 0
On Thursday, October 11, 2018 8:35:34 AM MDT James Japherson via
Digitalmars-d wrote:
> Took me about an hour to track this one down!
>
> A + (B == 0) ? 0 : C;
>
> D is evaluating it as
>
> (A + (B == 0)) ? 0 : C;
>
>
> The whole point of the parenthesis was to associate.
>
> I usually explicitly
On Thursday, October 11, 2018 1:09:14 PM MDT Jonathan Marler via
Digitalmars-d wrote:
> On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson
>
> wrote:
> > Took me about an hour to track this one down!
> >
> > A + (B == 0) ? 0 : C;
> >
> > D is evaluating it as
> >
> > (A + (B == 0)) ? 0
On 10/11/2018 07:35 AM, James Japherson wrote:
Took me about an hour to track this one down!
A + (B == 0) ? 0 : C;
D is evaluating it as
(A + (B == 0)) ? 0 : C;
Friends don't let friends use the ternary operator except in trivial cases.
This would be a good thing for a linter to check.
On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson
wrote:
Took me about an hour to track this one down!
A + (B == 0) ? 0 : C;
D is evaluating it as
(A + (B == 0)) ? 0 : C;
The whole point of the parenthesis was to associate.
I usually explicitly associate precisely because of
On 11/10/18 20:16, Kagamin wrote:
On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson wrote:
In the ternary operator it should treat parenthesis directly to the
left as the argument.
I don't think parentheses are ever treated like that. They are
self-contained and don't affect
On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson
wrote:
Took me about an hour to track this one down!
A + (B == 0) ? 0 : C;
D is evaluating it as
(A + (B == 0)) ? 0 : C;
As it should.
The whole point of the parenthesis was to associate.
I usually explicitly associate
On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson
wrote:
In the ternary operator it should treat parenthesis directly to
the left as the argument.
I don't think parentheses are ever treated like that. They are
self-contained and don't affect operators outside them.
On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson
wrote:
Took me about an hour to track this one down!
A + (B == 0) ? 0 : C;
D is evaluating it as
(A + (B == 0)) ? 0 : C;
The whole point of the parenthesis was to associate.
I usually explicitly associate precisely because of
On 12/10/2018 3:35 AM, James Japherson wrote:
Took me about an hour to track this one down!
A + (B == 0) ? 0 : C;
D is evaluating it as
(A + (B == 0)) ? 0 : C;
The whole point of the parenthesis was to associate.
I usually explicitly associate precisely because of this!
A + ((B == 0) ? 0
On Thursday, 6 September 2018 at 15:56:50 UTC, Jonathan M Davis
wrote:
However, since attributes are applied to functions, and
__gshared is for variables, it really wouldn't make sense to
have @gshared, and by that same token, it wouldn't make sense
to have @ctlocal.
I don't see any reason
On Thursday, September 6, 2018 3:11:14 AM MDT Dechcaudron via Digitalmars-d
wrote:
> On Wednesday, 5 September 2018 at 11:39:31 UTC, Jonathan M Davis
>
> wrote:
> > Conceptually, what Timon is talking about doing here is to add
> > an attribute to symbols declared within a static foreach where
>
On Wednesday, 5 September 2018 at 11:39:31 UTC, Jonathan M Davis
wrote:
Conceptually, what Timon is talking about doing here is to add
an attribute to symbols declared within a static foreach where
that attribute indicates that the symbol is temporary (or at
least scoped to a particular
On 05.09.2018 12:29, Dechcaudron wrote:
On Tuesday, 4 September 2018 at 19:50:27 UTC, Timon Gehr wrote:
The only blocker is finding a good syntax.
How does "static enum" sound?
It can't be anything that is legal code today (__local works for all
declarations, not just enums).
On 05.09.2018 14:41, Andre Pany wrote:
On Wednesday, 5 September 2018 at 12:05:59 UTC, rikki cattermole wrote:
Indeed. scope enum would make much more sense.
scope enum sounds a lot better for me than static enum or even __local.
The __ words looks a little bit like compiler magic as the __
On 06/09/2018 12:52 AM, JN wrote:
On Wednesday, 5 September 2018 at 12:41:05 UTC, Andre Pany wrote:
On Wednesday, 5 September 2018 at 12:05:59 UTC, rikki cattermole wrote:
Indeed. scope enum would make much more sense.
scope enum sounds a lot better for me than static enum or even
__local.
On Wednesday, 5 September 2018 at 12:41:05 UTC, Andre Pany wrote:
On Wednesday, 5 September 2018 at 12:05:59 UTC, rikki
cattermole wrote:
Indeed. scope enum would make much more sense.
scope enum sounds a lot better for me than static enum or even
__local. The __ words looks a little bit
On Wednesday, 5 September 2018 at 12:05:59 UTC, rikki cattermole
wrote:
Indeed. scope enum would make much more sense.
scope enum sounds a lot better for me than static enum or even
__local. The __ words looks a little bit like compiler magic as
the __ words are reserved for the compiler.
On 05/09/2018 11:39 PM, Jonathan M Davis wrote:
On Wednesday, September 5, 2018 5:19:04 AM MDT Dechcaudron via Digitalmars-d
wrote:
On Wednesday, 5 September 2018 at 10:45:20 UTC, Jonathan M Davis
wrote:
Too many people already think that the point of static is to
just make something be done
On Wednesday, September 5, 2018 5:19:04 AM MDT Dechcaudron via Digitalmars-d
wrote:
> On Wednesday, 5 September 2018 at 10:45:20 UTC, Jonathan M Davis
>
> wrote:
> > Too many people already think that the point of static is to
> > just make something be done at compile time (which is actually
> >
On Wednesday, 5 September 2018 at 10:45:20 UTC, Jonathan M Davis
wrote:
Too many people already think that the point of static is to
just make something be done at compile time (which is actually
a pretty terrible reason to use static) without adding that
sort of thing into the confusion.
On Wednesday, September 5, 2018 4:29:32 AM MDT Dechcaudron via Digitalmars-d
wrote:
> On Tuesday, 4 September 2018 at 19:50:27 UTC, Timon Gehr wrote:
> > The only blocker is finding a good syntax.
>
> How does "static enum" sound?
Like it would be really, really confusing. Too many people
On Tuesday, 4 September 2018 at 19:50:27 UTC, Timon Gehr wrote:
The only blocker is finding a good syntax.
How does "static enum" sound?
On 02.09.2018 15:45, bauss wrote:
On Sunday, 2 September 2018 at 13:26:55 UTC, Petar Kirov [ZombineDev]
wrote:
It's intended, but with the possibility to add special syntax for
local declarations in the future left open, as per:
On Monday, 3 September 2018 at 18:03:18 UTC, Soma wrote:
Sorry to disrupt your threat, but as a lurking in this forum
using D for small projects, and after looking such snippet my
first impression is how D is getting polluted and becoming more
like Java and C++.
"final class", "public final
On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:
unmaintainable piece of code:
```
final class ClassName : SoapBinding, Interface
{
public:
final:
this()
{
super();
}
import __stdtraits = std.traits;
static foreach (member; __traits(derivedMembers, Interface))
{
n Monday, September 3, 2018 12:39:17 AM MDT Neia Neutuladh via Digitalmars-d
wrote:
> On Monday, 3 September 2018 at 04:43:30 UTC, bauss wrote:
> > On Sunday, 2 September 2018 at 20:01:08 UTC, Neia Neutuladh
> >
> > wrote:
> >> On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:
> >>> Woud
On Monday, 3 September 2018 at 06:39:17 UTC, Neia Neutuladh wrote:
On Monday, 3 September 2018 at 04:43:30 UTC, bauss wrote:
On Sunday, 2 September 2018 at 20:01:08 UTC, Neia Neutuladh
wrote:
On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:
Woud be so much more maintainable if I could
On Monday, 3 September 2018 at 04:43:30 UTC, bauss wrote:
On Sunday, 2 September 2018 at 20:01:08 UTC, Neia Neutuladh
wrote:
On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:
Woud be so much more maintainable if I could have each
statement into a variable that could be maintained
On Sunday, 2 September 2018 at 20:01:08 UTC, Neia Neutuladh wrote:
On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:
Woud be so much more maintainable if I could have each
statement into a variable that could be maintained properly.
You could extract the body of the static foreach
On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote:
Woud be so much more maintainable if I could have each
statement into a variable that could be maintained properly.
You could extract the body of the static foreach into a
[template] function.
1 - 100 of 531 matches
Mail list logo
