On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote:
The @trusted contract says that an @trusted function must be
safe when called from an @safe function. That calling @safe
function might be located in the same module, meaning it might
have the same level of access as the @trusted funct
On Saturday, 29 September 2018 at 02:22:55 UTC, Shachar Shemesh
wrote:
I missed something he said in one of the other (as of this
writing, 98) posts of this thread, and thus causing Dukc to
label me a bullshitter.
I know you meant Sarn, but still... can you please be a bit less
aggresive with
On Friday, 28 September 2018 at 02:23:32 UTC, sarn wrote:
Shachar seems to be aiming for an internet high score by
shooting down threads without reading them. You have better
things to do.
http://www.paulgraham.com/vb.html
I believe you're being too harsh. It's easy to miss a part of a
po
On Wednesday, 26 September 2018 at 07:37:28 UTC, Shachar Shemesh
wrote:
The other type of answer is "it's being done in the real
world". If it's in active use in the real world, it might make
sense to support it, even if we can agree that the design is
not optimal.
Shachar
Two years ago, I
On Wednesday, 26 September 2018 at 06:50:47 UTC, Shachar Shemesh
wrote:
The properties that cause city names to be poor candidates for
enum values are the same as those that make them Unicode
candidates.
How so?
City names (data, changes over time) as enums (compile time
set) seem like a hor
When I make code that I expect to be only used around here, I
generally write the code itself in english but comments in my own
language. I agree that in general, it's better to stick with
english in identifiers when the programming language and the
standard library is English.
On Tuesday, 25
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat
wrote:
Not Weka but we are happy with @nogc and without @nogc our job
would be impossible.
There is one way to code without garbage collector somewhat
practically without annotating @nogc, the way I use: Compile
manually only tho
On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
// D
auto a = "á";
auto b = "á";
auto c = "\u200B";
auto x = a ~ c ~ a;
auto y = b ~ c ~ b;
writeln(a.length); // 2 wtf
writeln(b.length); // 3 wtf
writeln(x.length); // 7 wtf
writeln(y.length); // 9 wtf
writeln(a == b); // false wtf
On Friday, 24 August 2018 at 22:04:49 UTC, H. S. Teoh wrote:
I don't know how to reconcile these two. Perhaps if we had the
manpower, we could maintain older versions for long enough to
allow users to gradually rewrite to work with newer compilers,
while the development branch can be bolder in
On Thursday, 23 August 2018 at 04:44:47 UTC, Shachar Shemesh
wrote:
But, again, it is interesting to see what you took from my mail.
I think the biggest problem is lack of reviewers when making
PR:s. The fact that we have D language foundation, state of D
survey, extensive autotester and regu
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh
wrote:
Every single one of the people rushing to defend D at the time
has since come around. There is still some debate on whether,
points vs. counter points, choosing D was a good idea, but the
overwhelming consensus inside Weka toda
On Thursday, 16 August 2018 at 14:11:20 UTC, Andrei Alexandrescu
wrote:
we're working on a HOPL submission.
What's HOPL?
On Friday, 17 August 2018 at 13:39:29 UTC, Steven Schveighoffer
wrote:
On 8/17/18 3:36 AM, Atila Neves wrote:
Here's a struct:
-
// used to be scope int* ptr() { return ints; }
scope inout(int)* ptr() inout { return ints; }
Does scope apply to the return value or the `this` ref
On Saturday, 11 August 2018 at 10:04:14 UTC, Nicholas Wilson
wrote:
On Friday, 10 August 2018 at 13:15:46 UTC, Dukc wrote:
The benefit would be that null can be a regular pointer
constant (enum null = typeof(&assert(false)).init) instead of
a symbol with special meaning. I'd think it makes comp
On Saturday, 11 August 2018 at 05:01:50 UTC, docandrew wrote:
On Thursday, 9 August 2018 at 15:50:02 UTC, w0rp wrote:
A better name for this type is `never`, which is the name of
the TypeScript type with similar semantics.
https://www.typescriptlang.org/docs/handbook/basic-types.html#never `not
On Friday, 10 August 2018 at 12:42:37 UTC, Nicholas Wilson wrote:
meant is(typeof(*null) == typeof(assert(0)))
How is that a good thing??? Also that is not specified in the
dip. I would expect that to fail because both will produce
error nodes in the AST, only assert(0) is considered special
On Friday, 10 August 2018 at 11:28:38 UTC, Dukc wrote:
One example comes to mind: is(typeof(null) ==
typeof(assert(0))).
meant is(typeof(*null) == typeof(assert(0)))
On Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote:
* "[With @noreturn] other potential uses of a bottom type will
not be expressible". What other? Documentation and optimisation
definitely can be, the are in LDC since a long time, there are
no other substantiated benefits listed
On Tuesday, 24 July 2018 at 12:37:21 UTC, Cym13 wrote:
That argument sounds quite dangerous to me, especially since my
experience is on the contrary that constructor arguments are
often named the same as the attribute they refer to. And what
of mixed cases? I really wouldn't rely on anything li
On Monday, 23 July 2018 at 16:26:42 UTC, Seb wrote:
What's your take on this?
Option 2 won't necessarily cause problems with named funcion
arguments: The names of the constructor arguments and members are
different anyway, at least usually, letting the compiler to infer
the intended call by
On Monday, 23 July 2018 at 15:06:16 UTC, Ecstatic Coder wrote:
And something that REALLY must be integrated into BetterC's
low-level standard library in some way IMHO...
They already work, except for the concatenation operator because
it obviously requires the GC. And converiting a pointer fro
On Friday, 20 July 2018 at 23:19:08 UTC, Nicholas Wilson wrote:
On Friday, 20 July 2018 at 16:39:46 UTC, Dukc wrote:
How so? It could be made it act exactly as if the temporary
was made just before the function call, meaning the lifetime
would end at the end of current scope.
... which is e
On Friday, 20 July 2018 at 09:39:47 UTC, Nicholas Wilson wrote:
appending something (like .byRef or byRef!long, the latter
making an implicit type conversion)
That can't work: either it returns an expired stack temporary
(*very* bad), or allocates with no way to deallocate (bad).
How so? It
On Friday, 20 July 2018 at 09:24:19 UTC, Bastiaan Veelo wrote:
On Friday, 20 July 2018 at 09:03:18 UTC, Dukc wrote:
Thanks for the effort to make it... I believe Manu will be
pleased.
Manu is the one who wrote the DIP :-)
Though it was Mike :-)
On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
This is the feedback thread for the first round of Community
Review for DIP 1016, "ref T accepts r-values"
I'd prefer a solution which allows one to make an invisible temp
manually without making a new statement or a new symbol name.
On Thursday, 12 July 2018 at 10:38:52 UTC, Shachar Shemesh wrote:
On 12/07/18 04:17, Jonathan M Davis wrote:> I'm also> not sure
if going to copy constructors means that we should do
something> different with this. It don't think that it's
affected by it, but I could be> missing something.
I
On Thursday, 5 July 2018 at 10:27:52 UTC, Dukc wrote:
The DIP looks well written. I'm in favour of it.
However, we need to consider how well this interacts with
Razvan's DIP [1]. We should consider this together with it, so
the implementations do not end up messing each other.
1:
https://f
On Thursday, 5 July 2018 at 16:12:08 UTC, Atila Neves wrote:
On Thursday, 5 July 2018 at 10:57:51 UTC, Dukc wrote:
D does not have default constructors for structs, but I have
thought that this might get around the problem:
[...]
You already have that capability:
struct HandGrenade {
vo
On Thursday, 5 July 2018 at 15:58:14 UTC, Andrea Fontana wrote:
On Thursday, 5 July 2018 at 10:57:51 UTC, Dukc wrote:
If not, should we in your opinion have an ability to define an
alternative destructor which runs only when explicitly
requested?
What does "when explicity requested" mean?
T
On Thursday, 5 July 2018 at 12:50:18 UTC, Ivan Kazmenko wrote:
Is there any better way? To prevent introducing bugs when
micro-optimizing, I'd like the loop body to remain as unchanged
as it can be.
foreach(j, ref piece; cast(int[4][]) a)
{ auto pieceI = j * 4;
static foreach(i; 0 .. pi
D does not have default constructors for structs, but I have
thought that this might get around the problem:
struct MallocedPtr()
{ void* location;
~this()
{ import core.stdc.stdlib;
assert(location != null);
free(location.ptr);
}
}
Unlike a destructor which has
On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote:
DIP 1014, "Hooking D's struct move semantics", is now ready for
final review.
Structs are a low level feature that should be able to be used in
any way programmer sees fit. This is just what is wrong with C#
structs: In principle
On Sunday, 17 June 2018 at 20:17:36 UTC, Dukc wrote:
Yes, I agree. And each too, of course.
Thought again and not so sure anymore: I just realized that if we
are to do that, it should apply the same changes to tee, find,
filter etc. Probably too complicated to be worth it.
For @nogc, there
On Sunday, 17 June 2018 at 13:50:31 UTC, Seb wrote:
On Saturday, 16 June 2018 at 11:58:47 UTC, Dukc wrote:
What are your thoughts? Do you agree with this coding pattern?
It would even be better if map can recognize tuples and thus
allows to simply use a lambda functions with two parameters,
I think I have just found a pattern to ease the pain of @nogc
programming somewhat. Consider this:
import std.algorithm;
import std.range;
@nogc void main()
{ import core.stdc.stdio;
int power = 2;
foreach
( raised;
iota(10)
.dropOne
.map!(num => num^^pow
On Saturday, 26 May 2018 at 12:37:15 UTC, rumbu wrote:
Therefore your first example will work correctly if you convert
the int result back to char: (char)('a' + 'b') + "s" will
render the correct result.
Even if C# would use '~' instead of '+', you had a type
conversion problem, not an op
On Saturday, 26 May 2018 at 11:04:44 UTC, Nick Treleaven wrote:
I don't think it makes sense to allow adding two characters -
the second operand should be an integer type.
So it would behave like pointer arithmetic. Sounds sound. Not for
D because of the C semantic similarity requirement but
On Saturday, 26 May 2018 at 09:01:29 UTC, rumbu wrote:
Sorry, but the mistake here is the fact that you wrongly assume
C behavior in C#.
Yes it is. But that does not make differentiating concat and
addition in language desing any less worthwhile. In car crashes,
the mistake is usually made by
On Friday, 25 May 2018 at 23:57:03 UTC, IntegratedDimensions
wrote:
So, you think by forcing programmers to use a break, goto, or
return at the end of a case somes errors but really what it
does it make programmers less aware of the problems. They
become less effective programmers in the long r
On Saturday, 26 May 2018 at 03:34:50 UTC, Walter Bright wrote:
For unprofessional demeanor, I recommend reddit.
Wat?!?
On Friday, 25 May 2018 at 21:06:17 UTC, Walter Bright wrote:
This ambiguity bug with + has been causing well-known problems
since Algol. A *really* long time. Yet it gets constantly
welded into new languages.
Yeah. I could understand that choice for a language that tries to
be simple for be
I was programming in C# and wanted to format an int in
hexadecimal. It may be that I should have used some library
function for that, but I decided to roll my own function for that
anyway, in my general utility class:
public static string FormatHexadecimal(int what)
{ if (what == 0) return "
On Thursday, 24 May 2018 at 07:07:48 UTC, Jonathan M Davis wrote:
It's true.
Should somebody of us make an Announce theard out of this?
On Wednesday, 23 May 2018 at 12:32:50 UTC, Steven Schveighoffer
wrote:
and in others he has impersonated WalterBright as well.
-Steve
Sorry forgot that part in my last post. If that's true, it makes
it VERY serious.
On Wednesday, 23 May 2018 at 17:31:40 UTC, Steven Schveighoffer
wrote:
The IP address is included in the headers of the newsgroup. All
of them came from the same IP. I have a filter on my
thunderbird client to flag certain IPs, and his was added to
the list recently.
Then again, it's possible
On Wednesday, 23 May 2018 at 03:44:36 UTC, Manu wrote:
alias this ¤%[&Off; // <-- symbols are now aliased where they
I think it could be
with (¤%[&Off):
also.
On Tuesday, 15 May 2018 at 06:38:04 UTC, KingJoffrey wrote:
Can you give me some examples?
Defining a Voldemort type (meaning, one whose name is not public)
with private members for use by multiple functions:
---
module two_functions;
private struct MyForwardRange
{ private int functi
On Monday, 14 May 2018 at 07:59:06 UTC, Jonathan M Davis wrote:
On Monday, May 14, 2018 07:03:35 Dukc via Digitalmars-d wrote:
On Monday, 14 May 2018 at 07:02:37 UTC, Dukc wrote:
module test;
void main() { foo.i = 2; }
void foo() { static int i = 1; }
If that's
On Saturday, 12 May 2018 at 15:48:53 UTC, KingJoffrey wrote:
On Saturday, 12 May 2018 at 13:38:18 UTC, Walter Bright wrote:
Mike's right. D's encapsulation model is designed around the
module.
Actually, that is not true. If it were true, then I could do:
module test;
void main(
On Monday, 14 May 2018 at 07:02:37 UTC, Dukc wrote:
module test;
void main() { foo.i = 2; }
of encapsulation
void foo() { static int i = 1; }
meant
module test;
void main() { foo.i = 2; }
void foo() { static int i = 1; }
On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote:
...
// constructor of DataStructure
this(Allocator alloc=__ALLOC__) {...}
...
auto alloc = new SomeAllocator();
define __ALLOC__ = alloc;
// And we don't need to pass alloc everytime
...
Is this a good idea?
Doesn't this basically me
On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:
On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:
`private` is for outside the module. Within the module,
private is not applied because D wanted to avoid C++'s
`friend` functions.
'private' is "meant" to be part of the implemen
On Monday, 2 April 2018 at 07:05:45 UTC, Mike Parker wrote:
[snip]
I like this. A goto-reference as of how and when to deprectate
and remove.
About the concerns that depractation period being measured by
releases could fluctate the interval, I definitely would have
agreed in autumn 2016. B
On Monday, 2 April 2018 at 17:30:20 UTC, Paulo Pinto wrote:
- No code that would trigger GC is allowed
Impressive! It definitely won't be anyhing like D or Rust in
systems field anyway, but C# usually feels to be so reliant in GC
that this sounds wonderous nonetheless! Especially if, even
wi
On Wednesday, 7 March 2018 at 16:29:33 UTC, Seb wrote:
Well, I tried that already:
https://github.com/dlang/phobos/pull/5513
In short: very easy to do, but not much interest at the time.
No. The main problem with that (and the idea of using a compiler
flag in general) is that it affects the
On Monday, 5 March 2018 at 05:43:36 UTC, Ali wrote:
i think he means this article
https://www.excelsiorjet.com/blog/articles/conservative-gc-is-it-really-that-bad/
https://news.ycombinator.com/item?id=16436574
Thank you.
I don't think a just iterated array is automatically set to null,
so taking it's pointer won't hit a memory-proteted area. So
undeprectating arr.ptr in @safe would break @safety and be a step
backward.
If this is an issue, one can define a @trusted function which
takes a starting pointer from
On Friday, 16 February 2018 at 09:44:27 UTC, aberba wrote:
1. Do you first write it in idiomatic D style or a more general
approach before porting to idiomatic D?
In micro-level, it's usually fairly idiomatic from get-go.
Usually no heap allocations at inner loops, for-looping, static
variabl
On Tuesday, 13 February 2018 at 07:47:39 UTC, JN wrote:
"There are only two kinds of languages: the ones people
complain about and the ones nobody uses."
Wasn't that from Bjarne Stroustrup?
On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran
wrote:
Sorry if I'm hurting someone's sentiment, but is it just me who
is seeing so much negative trend in the D forum about D itself?
Well, programmers are engineers, and engineers tend to focus on
things that need improvement.
On Friday, 9 February 2018 at 21:24:14 UTC, Walter Bright wrote:
Of course, the issue can get more complex. GC uses 3x the
memory of RC, and so you can get extra slowdowns from swapping
and cache misses.
Is the total memory consumption tripled, or only the extra memory
used for tracking alloc
On Friday, 9 February 2018 at 18:31:18 UTC, H. S. Teoh wrote:
TBH, I'm not a fan of inout. Not because of how most people
feel, that we shouldn't have it; IMO it doesn't go *far
enough*. For example, there's currently no way to express
conveying the constness of a delegate argument's paramet
On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
Which language futures by your opinion make D harder?
Not many! D is a fairly complex languague, but just about
everything feels like to be here for a good reason. That includes
many oft-hated things: inout, auto ref, goto, BetterC...
On Monday, 29 January 2018 at 17:51:40 UTC, Seb wrote:
- All high-level code should be usable in @safe
This is not currently possible with functions that take a
delegate parameter, including opApply. (without sacrificing
genericity)
A DIP could be made so that the function infers it's attr
Is it intended to be updated? No pressure, just making sure it's
not forgotten...
On Wednesday, 17 January 2018 at 02:19:11 UTC, Seb wrote:
So do you have a good use cases for this?
If this is a useful feature, the implementation can be improved
to be zero-cost for normal runs.
If a GUI button simply executes a function. Tooltip for it could
be generated from the function
On Friday, 12 January 2018 at 21:24:40 UTC, John Gabriele wrote:
1. It has its own name. Phobos. This is unusual. I don't know
of any other language who's std lib has any name other than
"the {lang} standard library". Why does it have its own
distinct name, and why do I (as a user) need to kno
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote:
Another issue is I've had the flu for a while which makes me
tired, and then it's best to work on things that don't require
much mental energy.
I quess that applies easily twice as strongly if you code bigger
things on the run, n
On Wednesday, 13 December 2017 at 10:15:10 UTC, ag0aep6g wrote:
`front` can't assume that `empty` has been called before. For a
well-behaved range, `front` must work the same whether you've
called `empty` or not (given that the range isn't actually
empty).
That last point is what I meant: i
On Tuesday, 12 December 2017 at 23:43:19 UTC, Luís Marques wrote:
Well, I was referring to things like in front() having to use
code such as `if(!inited) ...; return value
I think you only have to do that if you have some custom pointer
arithmetic and you want to make sure it remains memory sa
On Tuesday, 28 November 2017 at 16:14:52 UTC, Jack Stouffer wrote:
you can apply attributes to your whole project by adding them
to main
void main(string[] args) @safe {}
Although this isn't recommended, as almost no program can be
completely safe.
In fact I believe it is. When you have so
On Monday, 20 November 2017 at 10:45:20 UTC, Dukc wrote:
A type that wraps a reference type behaving like a value type.
Default initialized value and what to do on copy would be
passed as template parameters. Perhaps I should try...
Just realized Unique!T is already pretty close. A few
(non-b
On Sunday, 19 November 2017 at 04:04:04 UTC, Walter Bright wrote:
Interestingly, `int` isn't nullable, and we routinely use
rather ugly hacks to fake it being nullable, like reserving a
bit pattern like 0, -1 or 0xDEADBEEF and calling it
INVALID_VALUE, or carrying around some other separate fla
On Thursday, 16 November 2017 at 23:03:10 UTC, H. S. Teoh wrote:
For an official logo, though, I'd expect something more
refined. The concept itself seems workable.
T
Unfortunately, I'm no artist. It would probably look worse if I
tried to refine it much from that.
On Wednesday, 15 November 2017 at 14:56:53 UTC, Andrei
Alexandrescu wrote:
Hello, for all of you with expertise in graphics, we'd be in
your debt if you could create a logo for DConf 2018. Proposals
would be appreciated!
Thanks,
Andrei
Probably too crude to be worth considering but feel fre
On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote:
For example, suppose you're using a proprietary library that
provides a class X that behaves pretty closely to a range, but
doesn't quite have a range API. (Or any other API, really.)
Well, that's not a problem, you just write free
On Thursday, 26 October 2017 at 12:19:33 UTC, Steven
Schveighoffer wrote:
D's lookup rules fail miserably when it comes to templates:
mod1.d:
auto callFoo(T)(T t)
{
return t.foo;
}
mod2.d:
struct S
{
int x;
}
int foo(S s) { return s.x * 5; }
void main()
{
auto s = S(1);
assert(s.
On Wednesday, 18 October 2017 at 12:25:57 UTC, Ola Fosheim
Grøstad wrote:
I don't think C# force you to use object oriented modelling?
Clearly the GC and the standard library skews what you end up
doing.
Perhaps. Well, contrasted to .Net and JVM standard libraries then?
Ironically there is
On Wednesday, 18 October 2017 at 00:05:06 UTC, codephantom wrote:
Again, philosophy != religion. Why do these terms get confused
so much?
I didn't mean they would be. I think that "D is not a religion"
means that whatever philosophy it has it is not cast in stone.
Not that it has no philosoph
On Monday, 16 October 2017 at 00:25:32 UTC, codephantom wrote:
Is philosophy not important?
I think that if somebody wants to nail down a philosophy for D,
the main page puts it well: "The best paradigm is to not impose
something at the expense of others". I also heard that long ago
there wa
On Thursday, 5 October 2017 at 11:22:27 UTC, nkm1 wrote:
It works, yes. The point is, additional methods in the struct
body, and free standing functions outside of the body, but in
the same module, is basically the same thing in D (I believe
Andrei already mentioned that).
But I meant extend
On Thursday, 5 October 2017 at 10:07:31 UTC, nkm1 wrote:
Am I missing something? You can already extend the original
struct:
extern(c) struct Crng
{ int seedA;
int seedB;
ubyte[] restOfTheData;
extern (D) {
// or without extern (D)...
auto front() { return current
On Thursday, 5 October 2017 at 09:39:58 UTC, Dukc wrote:
On Thursday, 5 October 2017 at 09:26:44 UTC, Timon Gehr wrote:
The "fix" is to add
public import crng;
to _std.range_.
Yes, would work. I don't think it needs explanation why it's,
as you said, more like a "fix" than a fix.
Corr
On Thursday, 5 October 2017 at 09:26:44 UTC, Timon Gehr wrote:
(That module is crng itself.)
Depends on if he meant the extern (c) Crng or the
range-implementing Crng. But would still not work, unless i have
misunderstood something.
The "fix" is to add
public import crng;
to _std.ran
On Thursday, 5 October 2017 at 08:27:14 UTC, Dukc wrote:
and you have to rewrite many wrappers for Crng functions
despite the alias this because they either require return Crng
or gequire a pointer to one.
Of course, If we could find a way to automate this universally,
there would be much les
On Wednesday, 4 October 2017 at 17:56:16 UTC, Walter Bright wrote:
Please present an example.
Let's say you're importing a C library which defines random
function generators. They may be more random than Phobos rngs,
they might be crytpo secure or whatever so you want to use them.
It could b
On Wednesday, 4 October 2017 at 17:56:16 UTC, Walter Bright wrote:
Please present an example.
Let's say you're importing a C library which defines random
function generators. They may be more random than Phobos rngs,
they might be crytpo secure or whatever so you want to use them.
It could b
On Tuesday, 3 October 2017 at 19:25:32 UTC, Walter Bright wrote:
This is specifically designed to prevent nasty surprises. C++
has a big problem with ADL in that overloading is not
encapsulated and any #included header can inadvertently add
more overloads that may be entirely unrelated. Any .h
On Friday, 29 September 2017 at 09:12:54 UTC, Don Clugston wrote:
Guess what this prints
My guess is it prints "1".
By "guess" I mean it, I did not test! Anyway reminds me a lot of
very badly used gotos.
On Friday, 29 September 2017 at 01:51:36 UTC, Jerry wrote:
Don't know how many times I've accidentially used a pointer as
an array.
Using @safe let's the compiler to catch that. Well, in it you
can't use pointer arithmetic even explicitly, but if you have
many elements to point at you're usua
On Wednesday, 6 September 2017 at 17:30:44 UTC, Dukc wrote:
See David Simcha's talk at DConf 13 at 37:30, that's the basic
idea how I'm thinking the range would internally iterate.
Correction: The outer loop would iterate in steps like that but
the body would be different. It would each time c
On Wednesday, 6 September 2017 at 09:21:59 UTC, Petar Kirov
[ZombineDev] wrote:
On Tuesday, 5 September 2017 at 15:46:13 UTC, Dukc wrote:
[..]
Of course, if we want to support this we should construct a
high-level library template that chooses the correct vector
size for the platform, elimina
On Sunday, 27 August 2017 at 10:28:29 UTC, Dukc wrote:
I'm sure there are other good options too. The problem with
geany is that it's syntax highlighting and auto-completion
depend on having the file where the symbol's defined open. But
that's because it's primarily a lightweight editor, not so
On Tuesday, 5 September 2017 at 18:32:34 UTC, Johan Engelen wrote:
My point was that that is not workable. The "null dereference"
is a D language construct, not something that the machine is
doing. It's ridiculous to specify that reading from address
1_000_000 should crash the program, yet that
On Monday, 4 September 2017 at 18:03:51 UTC, Johan Engelen wrote:
It's need for auto-vectorization, for example.
I would support an LDC PR for adding a magic UDA to be able to
attach 'restrict' with C-semantics to function parameters. E.g.
```
// add restrict to parameters 1 and 2
void foo(i
On Sunday, 3 September 2017 at 03:04:58 UTC, Uknown wrote:
In C, the `restrict` keyword implies that 2 or more pointer
arguments in a function call do not point to the same data.
I really don't see where the restrict keyword is needed at all,
neither in C nor in D. If you want to imply to the
On Sunday, 27 August 2017 at 10:05:29 UTC, Nicholas Wilson wrote:
So I will be doing a workshop on programming for the biology
department at my university and I was wondering what would best
suit the users.
The following are a must:
support windows & mac ( the more consistent between the t
On Wednesday, 19 July 2017 at 15:38:08 UTC, Jack Stouffer wrote:
Unless you're saying that the above should work even though it
currently doesn't. Even then, I don't know about that. If your
type is complex enough to need a shared dtor then the dtor
probably needs to do some locking or extra ch
On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov
[ZombineDev] wrote:
I think Atila was talking about this one:
struct A
{
~this() {}
}
void main()
{
auto a = A();
shared b = A();
}
Shouldn't it be :
struct A
{
~this() shared {}
}
void main()
{
auto a = A(
On Wednesday, 19 July 2017 at 13:37:50 UTC, Adam D. Ruppe wrote:
I like it.
Me too. I think this should also apply to switch and with
statements. Perhaps while statements too.
1 - 100 of 152 matches
Mail list logo
