foreach(ref e; range)
{
}
On idea is to have `ref` foreach to say that you would like to
iterate your range without copying. The syntax could be:
foreach(e; ref range)
{
}
or:
ref foreach(e; range)
{
}
At least it will not break existing code. But this means that in
each case you should mak
On Saturday, 25 March 2017 at 18:19:34 UTC, Stefan Koch wrote:
On Saturday, 25 March 2017 at 18:10:30 UTC, Uranuz wrote:
What is a good practice to make a bug report if I can't give
some reduced case when problem occurs? Is it normal to just
put link to my repo and branch with this problem an
On Saturday, 25 March 2017 at 17:47:18 UTC, Stefan Koch wrote:
On Saturday, 25 March 2017 at 17:41:49 UTC, Uranuz wrote:
On Saturday, 25 March 2017 at 17:31:33 UTC, Stefan Koch wrote:
On Saturday, 25 March 2017 at 13:34:43 UTC, Uranuz wrote:
[...]
I can reproduce this.
The function which fai
On Saturday, 25 March 2017 at 17:31:33 UTC, Stefan Koch wrote:
On Saturday, 25 March 2017 at 13:34:43 UTC, Uranuz wrote:
On Saturday, 25 March 2017 at 07:57:11 UTC, Stefan Koch wrote:
[...]
If you wish to help. You are welcome) I created branch in my
repository `https://github.com/uranuz/ivy
On Saturday, 25 March 2017 at 07:57:11 UTC, Stefan Koch wrote:
On Saturday, 25 March 2017 at 06:56:40 UTC, Uranuz wrote:
After changes in my project tried to compile, but compiler
failed. Running dmd under GDB gives the following:
Program received signal SIGSEGV, Segmentation fault.
0x0
On Saturday, 25 March 2017 at 08:24:04 UTC, Stefan Koch wrote:
On Saturday, 25 March 2017 at 08:13:08 UTC, Uranuz wrote:
On Saturday, 25 March 2017 at 07:57:11 UTC, Stefan Koch wrote:
[...]
I just put debug messages on every `assert` and figured out it
fails on lines:
boo
On Saturday, 25 March 2017 at 07:57:11 UTC, Stefan Koch wrote:
On Saturday, 25 March 2017 at 06:56:40 UTC, Uranuz wrote:
After changes in my project tried to compile, but compiler
failed. Running dmd under GDB gives the following:
Program received signal SIGSEGV, Segmentation fault.
0x0
On Saturday, 25 March 2017 at 06:56:40 UTC, Uranuz wrote:
After changes in my project tried to compile, but compiler
failed. Running dmd under GDB gives the following:
Program received signal SIGSEGV, Segmentation fault.
0x005807a0 in Mangler::mangleFuncType(TypeFunction*,
TypeFunction*
On Saturday, 25 March 2017 at 06:56:40 UTC, Uranuz wrote:
After changes in my project tried to compile, but compiler
failed. Running dmd under GDB gives the following:
Program received signal SIGSEGV, Segmentation fault.
0x005807a0 in Mangler::mangleFuncType(TypeFunction*,
TypeFunction*
After changes in my project tried to compile, but compiler
failed. Running dmd under GDB gives the following:
Program received signal SIGSEGV, Segmentation fault.
0x005807a0 in Mangler::mangleFuncType(TypeFunction*,
TypeFunction*, unsigned char, Type*) ()
Could someone give me adivice
code.dlang.org 500 Internal Server Error
Does anyone experience the same probleme?
On Saturday, 25 June 2016 at 10:19:47 UTC, Claude wrote:
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
My 2 cents. I don't find that annoying at all. It's perfectly
normal IMHO.
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
What I think about enchancement of static if is that it could be
interesting to have `elif` keyword like in Python, so instead of
s
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh
wrote:
Please consider the following program, which is a reduced
version of a problem I've spent the entire of today trying to
debug:
import std.stdio;
void main() {
enum ulong MAX_VAL = 256;
long value = -500;
if( valu
On Monday, 18 January 2016 at 10:20:13 UTC, Vladimir Panteleev
wrote:
As the new design rolled out on dlang.org, I decided to push
the changes on forum.dlang.org as well. From what I gathered
from the previous feedback thread, I believe we've addressed
the most stringent issues. Once again than
On Wednesday, 8 July 2015 at 08:24:00 UTC, Martin Nowak wrote:
On Wednesday, 8 July 2015 at 06:11:25 UTC, Uranuz wrote:
My idea is slihtly of topic.
I thiking about some API for array and associative array
literals.
There is already an API for array literals, typesafe variadic
arguments.
v
On Saturday, 30 May 2015 at 08:22:21 UTC, Martin Nowak wrote:
On Saturday, 30 May 2015 at 00:50:39 UTC, Steven Schveighoffer
wrote:
I suggest first we build a library AA that sits beside real
AA, even if it doesn't . Then we create a test suite to prove
that the library AA can be a drop in repl
If we will have something like *scoped destructor* (that will be
executed at scope exit) could it help to release some resources?
I worry about this problem too because even using class to hold
resource I expirience some *delays* in relesing them. For example
I have database connection opened.
When I want to pass generic String by const reference I get an
error. As far as I understand const should accept both mutable
and immutable data. And there I want to pass it by reference. Is
it possible? Or is there any reason why it is not? Is it a bug?
void doSmth(String)(ref const(String) s
I did something similar a while back. It parsed a .ini that
contained default values and created a statically typed runtime
parser for the actual .ini file from it. It was fun, to see
that you can do that with D.
Yes. I use import('filename') to configure my application too. I
have config.json,
auto p1 = setExtension("hello", ".txt"); // fine, use gc
auto p2 = setExtension!gc("hello", ".txt"); // same
auto p3 = setExtension!rc("hello", ".txt"); // fine, use rc
So by default it's going to continue being business as usual,
but certain functions will allow passing in a (defaulted)
policy
It's Tolstoy actually:
http://en.wikipedia.org/wiki/War_and_Peace
You don't need byGrapheme for simple DSL. In fact as long as
DSL is simple enough (ASCII only) you may safely avoid
decoding. If it's in Russian you might want to decode. Even in
this case there are ways to avoid decoding, it ma
I totally agree with all of that.
It's one of those cases where correct by default is far too
slow (that would have to be graphemes) but fast by default is
far too broken. Better to force an explicit choice.
There is no magic bullet for unicode in a systems language such
as D. The programmer
On Sunday, 28 September 2014 at 00:13:59 UTC, Andrei Alexandrescu
wrote:
On 9/27/14, 3:40 PM, H. S. Teoh via Digitalmars-d wrote:
If we can get Andrei on board, I'm all for killing off
autodecoding.
That's rather vague; it's unclear what would replace it. --
Andrei
I believe that removing a
Also it's interesting waht is the correspondence between memory
management, memory model and allocators? I know that
std.allocator is in development. I guess that it should be
considered in complex.
I'm quite a noobie in memory models but from position of user of
D language I have some ideas about syntax of switching between
memory models. I think that having everywhere declarations using
wrapper structs (like RefCounted) is not very user-friendly. But
still we need some way to say to comp
On Tuesday, 26 August 2014 at 18:29:49 UTC, Uranuz wrote:
On Tuesday, 26 August 2014 at 16:48:08 UTC, Timon Gehr wrote:
On 08/26/2014 05:46 PM, Uranuz wrote:
In the pre-last paragraph please read text^
Also notice that C is language with weak type system but D is
declared to have type system.
On Tuesday, 26 August 2014 at 16:48:08 UTC, Timon Gehr wrote:
On 08/26/2014 05:46 PM, Uranuz wrote:
In the pre-last paragraph please read text^
Also notice that C is language with weak type system but D is
declared to have type system.
as:
Also notice that C is language with weak type system bu
In the pre-last paragraph please read text^
Also notice that C is language with weak type system but D is
declared to have type system.
as:
Also notice that C is language with weak type system but D is
declared to have *strong* type system.
OK. Nobody ansvered anything yet. So I was thinking about this
problem for a while so I figured out possible soulution.
What I can do in this situation in to forbid these opertions and
make compiler issue an error during compilation or implement
functionality for all types that implicitly conv
I revived this topic, because I have similar problem but with
additional requirements.
I have interface and some classes that inherits from it. Also I
have property two overloads of *set* properties with types int
and Nullable!int
There is listing of code that illustrates funny bug that I ha
On Friday, 22 August 2014 at 17:08:39 UTC, Vladimir Panteleev
wrote:
On Friday, 22 August 2014 at 08:47:23 UTC, Uranuz wrote:
In my project I have sort of complicated logic to implement
data structure that is somehow similar to std.typecons.Tuple.
I can't reproduce it, because I can't locate th
On Thursday, 21 August 2014 at 15:36:41 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 21 Aug 2014 15:27:46 +
MacAsm via Digitalmars-d wrote:
Any thoughts? I don't know if I'm missing something but two
functions (and not methods) with same name is very bad.
they doing much the same, but for
In my project I have sort of complicated logic to implement data
structure that is somehow similar to std.typecons.Tuple. I can't
reproduce it, because I can't locate the source of bug. My code
is like this but have more nested template "calls".
import std.stdio, std.typetuple;
struct MyLib(A
For now I can't an example of code. But sometimes I get Linker
errors on Ubuntu Linux when using *scoped imports*. May be this
issue happens on another platforms too. Does anybody experience
the same problem when compiling programmes?
I'll try to invent some example of code that illustrates th
On Thursday, 17 July 2014 at 17:27:37 UTC, bearophile wrote:
Uranuz:
OK. Thanks. Using casts everywhere for such case us quite
annoying. I've tested it for plain array it doesn't work too.
However issue is marked as solved for it.
It's not exactly the same issue. Issue 3543 seems more fittin
I posted in the wrong thread.
Ok, now I see what you mean. The title of the thread is a
little confusing because actually you are not talking only
about string-based enums.
It's OK. It happened because I understood this problem myself in
this way only during the discussion. So as I think there are 2
options. First is
On Saturday, 19 July 2014 at 15:27:27 UTC, Ali Çehreli wrote:
On 07/19/2014 04:53 AM, Uranuz wrote:
> When I tried to use std.conv.to to serialize enum values that
are based
> on string type I faced with situation that *to* not exactly
as I
> expected.
Maybe I misunderstand you but the behavior
On Saturday, 19 July 2014 at 12:31:05 UTC, bearophile wrote:
1. So I want to know if it is expected behaviour?
Yes, this was the chosen behaviour.
2. What are the reasons for it?
It's one of the two main behaviours you may want, even if your
specific case it is not. It can be used to unse
When I tried to use std.conv.to to serialize enum values that are
based on string type I faced with situation that *to* not exactly
as I expected. As far as I understand it tries to find match
between passed string value and enum value identifier instead of
just casting it to enum type.
1. So
On Thursday, 17 July 2014 at 17:15:54 UTC, bearophile wrote:
interface IBase {}
class Impl(T): IBase {
T value;
}
void main() {
IBase a = true ? (new Impl!uint) : (new Impl!string);
}
I have added a note:
https://issues.dlang.org/show_bug.cgi?id=3543
Bye,
bearophile
OK. Thanks. Using c
Actualy I found this bug report, but I don't know if there
suggested something around associative arrays
https://issues.dlang.org/show_bug.cgi?id=5498
Seems that I saw similar post but about plain arrays somewhere
but currently I can't find it. The topic is that when I
initialize associative array of interfaces with AA-literal
consisting of derived class objects I get compiler error.
import std.stdio;
interface IBase
{
}
class Imp
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
Hello,
I've been D enthusiast for couple of years now (but I do not
participate much in discussions here, although I read forums
almost daily), and I keep telling people about D and how
awesome it is.
But, all this time D's
Thanks for response. I was thinking that adding new statement for
such feature is not very good too. Is there any recent
discussions about tuble literals. There is proposal in wiki but I
don't know if it will be accepted or not for some time. For now
seems like it's better to alias tuple and us
Very often I use associative array as the simple syntactic way of
representing of pairs of some values. But AAs are slightly
complicated for this task and they don't preserve order inside
it. I could use some struct for example
struct P(T, N)
{
T first;
N second;
}
and write something l
47 matches
Mail list logo
