On Tuesday, 21 June 2016 at 02:59:44 UTC, ZombineDev wrote:
I think it would be good idea to take this even further:
T4 foo(T4, T0, T1, Ts..., T2, T3)(T0 t0, T1 t1, Args args, T2
t2, T3 t3)
In other words, I think that the limitation that variadic
template parameter list must be at the end
On Tuesday, 21 June 2016 at 10:28:03 UTC, pineapple wrote:
On Tuesday, 21 June 2016 at 02:59:44 UTC, ZombineDev wrote:
I think it would be good idea to take this even further:
T4 foo(T4, T0, T1, Ts..., T2, T3)(T0 t0, T1 t1, Args args, T2
t2, T3 t3)
In other words, I think that the
On Sunday, 17 July 2016 at 02:03:52 UTC, Andrew Godfrey wrote:
2) I wonder if an "uninitialized" feature would be worthwhile.
That is, a value you can initialize a variable to, equal to
'init', but that static analyzers know you don't mean to ever
use.
Don't we already have this in the form
On Monday, 18 July 2016 at 09:01:43 UTC, Manu wrote:
I want a version of splitter that doesn't eat the sentinels.
I want to split AT the sentinels, but the sentinel should be
the first
element of the bucket.
eg: assert(equal(splitter("hello world", ' '), [ "hello", " ",
" world" ]));
Note
On Monday, 18 July 2016 at 09:39:13 UTC, pineapple wrote:
I can't speak to phobos but you should achieve this behavior in
mach.range.split by changing just one line (I'll add some
cleaner support for this myself sometime soon using a template
argument, maybe later today?)
Can't push at the
On Monday, 18 July 2016 at 09:52:25 UTC, pineapple wrote:
Can't push at the moment but here you go
http://pastebin.com/f2TxDg8F
"hello world".split!(true, false)(' ') will enumerate ["hello",
" ", " world"].
Something I keep going back and forth on is the best way to
handle exception reporting in different contexts. There are so
many idioms to use here and none of them feel quite ideal. I'm
not sure the best way to improve it, but I'm hoping a discussion
might produce some useful ideas.
Some
On Thursday, 26 January 2017 at 06:40:59 UTC, drug wrote:
26.01.2017 09:32, Profile Anaysis пишет:
Why not make enum a comparable type to structs and classes?
They are static so they can't contain any mutable fields but
surely they
can contain methods? And especially they should be able to
I'm not sure whether this should be counted as a bug, but I ran
into it and thought it deserved mentioning. I've been testing
this with DMD on Windows.
I wrote this function to support parsing of strings as floating
point values:
On Sunday, 22 January 2017 at 01:54:59 UTC, pineapple wrote:
When you write `real x = 0.0005;` x in fact represets a value
of about
0.00050032187251995663412884596255025826394.
This is a about 3.2 * 10^-23 more than 0.0005.
The output of my function in this case was about
On Sunday, 29 January 2017 at 02:52:51 UTC, Stefan Koch wrote:
Yes exactly that. many times in phobos foreach(dchar ch;
some_string)
which requires me to encode the utf8 string temporarily into
utf32
and then when it is appending to some other string I need to
reencode it into utf8.
Oooh, I
On Sunday, 29 January 2017 at 02:17:12 UTC, Stefan Koch wrote:
Also my ctfe engine still requires utf8 support, for
string-foreach.
Currently there are methods for that in druntime, I hope to
simply call them at ctfe, rather then re-implement them. If
someone volunteers I can provide help to
On Tuesday, 21 February 2017 at 18:32:22 UTC, Nick Sabalausky
(Abscissa) wrote:
On 02/21/2017 10:34 AM, Paul wrote:
3) Is there much value in taking programming classes that
don't deal
with D?
Although HR folk never understand this, programming skills are
highly transferable across
On Monday, 5 September 2016 at 18:27:44 UTC, ag0aep6g wrote:
Can you point out how this is different from (and better than)
try { do_a_thing(); depends_on_success_of_thing(); }
catch (...) { ... }
finally { ... }
?
On Monday, 5 September 2016 at 18:27:52 UTC, arturg wrote:
hm,
I was writing some code and realized D doesn't have an equivalent
to Python's `else` for error handling, and I think we should
change that
https://github.com/dlang/DIPs/pull/43/files
In Python, the try/catch/finally syntax is augmented with an
additional clause,
termed else. It is a
On Monday, 5 September 2016 at 19:12:02 UTC, Jacob Carlborg wrote:
On 2016-09-05 20:57, pineapple wrote:
In this case, the catch block will catch both errors from
do_a_thing and
depends_on_success_of_thing.
Then move it to after the "finally" block.
It would actually have to be inside the
On Tuesday, 30 August 2016 at 13:38:51 UTC, Chris Wright wrote:
Placing the condition at the end reflects the fact that the
condition is executed at the end of the loop.
I'm aware of that, but the syntax is inconsistent and harder to
read.
On Sunday, 28 August 2016 at 16:17:31 UTC, Cauterite wrote:
I dunno man, it seems all backwards to me. If you're gonna do
it this way, then you'd also want your if-statements like this:
{
foo();
bar();
} if (cond);
Could you imagine trying to read a function you didn't write
yourself
On Friday, 9 September 2016 at 12:09:32 UTC, Steven Schveighoffer
wrote:
I just had a thought. If you hash the string, and then compare
the length of the string and first and last character along
with the hash, what are the chances of it being a false
positive?
Any chance of a false positive
On Wednesday, 14 September 2016 at 18:36:46 UTC, Jonathan M Davis
wrote:
If you don't want to have problems with dereferencing null
pointers or references, then check for null in the cases where
a pointer or reference might be null.
- Jonathan M Davis
Writing your functions that disallow
On Thursday, 29 September 2016 at 11:45:42 UTC, Marc Schütz wrote:
On Wednesday, 28 September 2016 at 22:12:27 UTC, Idan Arye
wrote:
Foo foo;
try {
foo = Foo();
} catch (FooCreationException) {
// ...
} else {
foo.doSomethingWithFoo();
}
// foo
On Thursday, 29 September 2016 at 12:20:42 UTC, Russel Winder
wrote:
Opinionated is not always bad. Look at Go, the developers know
that
there is no sane way of doing generics so they ban it. Also
they know
that exceptions are totally incomprehensible to all programmers
so they
ban them. Rust
On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis
wrote:
Except that it kind of is. It's an example of a language
allowing you to mess with too much and make it so that it
doesn't function as expected, which is what happens when you
overload operators to act in a way inconsistent
On Thursday, 29 September 2016 at 18:38:42 UTC, Jonathan M Davis
wrote:
You just can't use overloaded operators for it, since it would
not be in line with what the operators are supposed to mean and
be used for.
This is not a valid argument because what an operator is
"supposed to mean" is up
On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis
wrote:
The reality of the matter is that D's operator overloading was
designed specifically so that you could overload the built-in
operators to be used with your own types so that they could act
like the built-in types. It was
On Thursday, 29 September 2016 at 18:56:40 UTC, Ilya Yaroshenko
wrote:
No, it does not
---
void foo(size_t[] I...)(I i)
{
}
Using phobos' allSatisfy or a similar template, this can become:
enum isIndex(T) = is(T == size_t);
void foo(I...)(I i) if(allSatisfy!(isIndex, I)){ ...
On Thursday, 6 October 2016 at 06:38:06 UTC, Jonathan M Davis
wrote:
Yeah, the fact that the body keyword is not required normally
but is when you have in/out contracts is annoying, completely
aside from what the keyword used is. I don't care much about
losing the name body to a keyword, but I
On Wednesday, 5 October 2016 at 19:02:02 UTC, Basile B. wrote:
On Wednesday, 5 October 2016 at 18:41:02 UTC, Jacob Carlborg
wrote:
On 2016-10-05 19:14, Matthias Klumpp wrote:
Agreed - I have exactly the same problem with "version",
which is also
really common for, well, to hold a version
On Friday, 16 September 2016 at 23:00:08 UTC, eugene wrote:
Hello everyone,
what if to remove semicolons at the end of each line of code in
D like in Python?
Is it worth it?
If you write JS in a professional environment, you will almost
certainly be required to terminate every line with a
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
There is no technical reason that would make the implementation
of this feature difficult, if that is your question.
Basically, the rationale is: external operators cannot be used
in generic code that does not import the
On Tuesday, 6 September 2016 at 07:26:37 UTC, Andrea Fontana
wrote:
Integer division and modulo are not bugs.
Quoted for emphasis
If you want floating point math, then declare your variables as
floats.
On Wednesday, 28 September 2016 at 17:56:13 UTC, Steven
Schveighoffer wrote:
The more I think about this submission, I feel like the
benefits are quite slim.
This is not and was not intended to be a glorious, incredible
addition to the language. It is meant to shove D a couple inches
further
On Wednesday, 28 September 2016 at 17:00:49 UTC, Lodovico
Giaretta wrote:
but a good compiler should be able to recognize functions with
the same code and fold them; for example, if a function takes a
generic pointer, chances are it doesn't need to be duplicated
for every pointer type.
But
On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright
wrote:
Because there is no way to stop the former but still have
operator overloading.
To reiterate, operator overloading exists in D to support the
inclusion of arithmetic library types. Any other purpose is
discouraged, and
On Wednesday, 28 September 2016 at 20:18:06 UTC, pineapple wrote:
This is not and was not intended to be a glorious, incredible
addition to the language. It is meant to shove D a couple
inches further in the direction of modern programming
constructs. Everywhere a programmer can use `else`
On Thursday, 29 September 2016 at 07:58:26 UTC, Walter Bright
wrote:
On 9/28/2016 11:48 PM, Jacob Carlborg wrote:
If that is not allowed, why is this allowed:
I.e. you can overload '+' to do bad things. Yes, you can, and
as I replied upthread that can be done because there's no way
to
On Thursday, 29 September 2016 at 10:51:01 UTC, Nick Treleaven
wrote:
Note that finally(bool) is more flexible than finally/else as
you can interleave code arbitrarily. __guard makes it clearer
something special is happening rather than just implicitly
extending `try` scope in the `else`
On Wednesday, 28 September 2016 at 07:47:32 UTC, Andrei
Alexandrescu wrote:
* Please remove colloquialisms. Characterizations such as
"fantastically useful" are unlikely to be a convincing
motivator and have no place in a DIP.
* The "Description" section should be more detailed and less
On Wednesday, 28 September 2016 at 07:33:48 UTC, ikod wrote:
Thanks!
There is also useful for/else construct in Python
https://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops
I'd like to see it in D.
While I appreciate being able to use
On Wednesday, 28 September 2016 at 03:28:50 UTC, Minty Fresh
wrote:
Using strings and mixins does have quite a number of downsides.
The additional work required to past the DSL aside, you also
usually lose the scope in which things are declared (especially
if you wish to reference or declare
I'd also like to point out a generally sound design principle:
Give the programmer as much power and flexibility as possible -
but don't forget to provide tools for simplifying common use
cases, and don't forget to define sensible defaults.
It makes a lot of sense that opCmp and opEquals
I submitted a PR addressing some of the mentioned criticisms:
https://github.com/dlang/DIPs/pull/46
On Friday, 30 September 2016 at 16:25:45 UTC, Jonathan M Davis
wrote:
But if you or anyone else wants to do wacky stuff with
overloaded operators that is not consistent with the built-in
types, you're free to do so within how D's overloaded operators
work. You're just not going to be able to
On Friday, 30 September 2016 at 22:38:07 UTC, Walter Bright wrote:
A more productive way forward is for you (and those who agree
with you) to prepare a formal DIP and submit it. It's the way
significant language change proposals are done.
A good idea.
I have written a rough initial draft for
On Sunday, 25 September 2016 at 04:06:41 UTC, Jonathan M Davis
wrote:
Considering that a random access range is essentially an
abstraction for a dynamic array and that ranges were designed
with that in mind, I don't know how you can argue that dynamic
arrays shouldn't be treated as ranges.
On Thursday, 22 September 2016 at 12:51:59 UTC, Andrei
Alexandrescu wrote:
On 9/22/16 6:38 AM, pineapple wrote:
The greatest offender I've found is how in phobos, arrays do
not behave
as ranges without importing the module defining their range
operations.
Would make sense to move those few
On Sunday, 25 September 2016 at 13:10:42 UTC, ZombineDev wrote:
But which opIndex and which length? Those of the container, or
those of the range? It doesn't make any sense to expect
container[].takeExactly(7).length to be different than 7. If
range.length returns the length of the container
On Sunday, 25 September 2016 at 11:48:38 UTC, Jonathan M Davis
wrote:
It's because ranges are effectively a sliding window over
whatever they're iterating over.
I think this is the difference in perception - ranges do not
_have_ to be sliding windows, they can just as well be windows
that
On Sunday, 25 September 2016 at 13:45:01 UTC, Andrei Alexandrescu
wrote:
Ranges don't need necessarily an associated Iterable. This is
the case in other languages, too; Lisp/Scheme/Haskell/etc lists
are iterables and at the same time their own iterators. But
indeed std.container is designed to
On Sunday, 25 September 2016 at 13:57:04 UTC, Jonathan M Davis
wrote:
The way it works now is how it's always worked with dynamic
arrays and ranges in D. If you're trying do anything else,
you're just going to run into problems in the long run -
particularly when interacting with code written
On Sunday, 25 September 2016 at 15:25:38 UTC, Jonathan M Davis
wrote:
So, if they want their code to work with anyone else's code
they pretty much need to use their own set of range primitives
that do not conflict with the standard ones rather than trying
to redefine the standard ones. And if
On Tuesday, 27 September 2016 at 09:48:42 UTC, Jonathan M Davis
wrote:
And why not just put the code that would go in the else at the
end of the try block? Just like with this proposed else, the
code would only run if the preceding code didn't throw any
exceptions. This just seems like an
On Tuesday, 27 September 2016 at 10:05:20 UTC, Idan Arye wrote:
BTW, if this feature is ever implemented in D, it's important
that the else clause will continue the try clause's scope.
The catch and finally clauses do currently continue the scope,
right? (If they don't, they probably should,
On Saturday, 1 October 2016 at 07:13:39 UTC, Martin Nowak wrote:
The fact that it's not possible to overload < but have to use
the ternary opCmp is even a performance problem. All std
algorithms only use less as a predicate, leading to lots of
unnecessary cycles when e.g. sorting UDTs.
On
On Wednesday, 26 October 2016 at 08:15:44 UTC, Basile B. wrote:
What would be possible is a "-fdmain" switch (force dummy
main). Its role would be: if a functionDeclaration named "main"
is present then this normal "main" is not used (technically
erased from the AST or something like that).
On Wednesday, 14 December 2016 at 01:53:44 UTC, Chris M. wrote:
How about using "imports" instead of "import"? Simple enough
change, and it still makes sense
bool equal(R1, R2)
imports (std.range)
if (isInputRange!R1 && isInputRange!R2)
{ ... }
On Tuesday, 13 December 2016 at 23:03:39 UTC,
On Sunday, 18 December 2016 at 02:40:59 UTC, Chris Wright wrote:
D doesn't have either of those pitfalls, so I haven't seen it
cause problems. I'm also a bit skeptical that this will see
much use outside phobos.
This isn't really an argument against it. I just don't see any
argument for it,
On Friday, 13 January 2017 at 21:15:32 UTC, André Puel wrote:
I think this could be useful when one is creating Idiom and
Patterns, you could hide implementations details.
I'm not sure that this is the kind of implementation detail that
ought to be hidden
On Sunday, 4 December 2016 at 11:18:56 UTC, rumbu wrote:
Yes, this is the same workaround I found, but that does not
solve the fact that the following code does not compile:
While it may be too late to redeem Phobos and its handling of
arrays as ranges, it is worth noting that in the library
On Saturday, 31 December 2016 at 17:02:55 UTC, Chris Wright wrote:
This extension removes an unforced limitation of the current
with syntax (allows it to occur at top level)
In other words, another aspect of this DIP is that I can write:
module foo;
static import std.traits;
static
On Sunday, 8 January 2017 at 14:42:57 UTC, pineapple wrote:
After deciding to let my inability to add some unit tests to
that module I started working on some other code in the same
project. At this point it seems completely arbitrary which
lines produce optlink errors. Since the `unittest{}`
On Sunday, 8 January 2017 at 14:15:26 UTC, pineapple wrote:
I'm working on my dumb library and I have run into a case where
when I add this line to a module, I get an optlink error
attempting to compile it:
unittest{}
After deciding to let my inability to add some unit tests to that
I'm working on my dumb library and I have run into a case where
when I add this line to a module, I get an optlink error
attempting to compile it:
unittest{}
The module compiles fine without it. So do the modules which
depend on it.
But with that line? optlink errors everywhere.
A
On Sunday, 8 January 2017 at 18:49:50 UTC, Walter Bright wrote:
Please post bug reports to bugzilla.
Here you go: https://issues.dlang.org/show_bug.cgi?id=17077
On Monday, 9 January 2017 at 02:34:31 UTC, Jerry wrote:
before I switched away from optlink. What point is there to
report these bugs though, Microsoft's linker works with fewer
bugs and actually supports the format of the platform. So no
need to convert .lib files with it. This is my point,
On Friday, 6 January 2017 at 09:54:32 UTC, Dmitry wrote:
On Thursday, 5 January 2017 at 22:37:21 UTC, solidstate1991
wrote:
I'm thinking on possibly implementing a scripting language for
my game engine for general purpose and AI. At one point I was
thinking on making a scripting language based
On Sunday, 18 December 2016 at 22:31:34 UTC, Andrei Alexandrescu
wrote:
Is there a simple command to e.g. unittest everything in the
project? Also, is there a build process or it's all templated?
-- Andrei
There's no build process. To run tests, I compile the root
`package.d` file with rdmd,
On Monday, 19 December 2016 at 00:44:14 UTC, pineapple wrote:
On Sunday, 18 December 2016 at 23:18:27 UTC, Andrei
Alexandrescu wrote:
Great, thanks. Please take a look at the accuracy of the
discussion. I expanded the "Workaround" section and moved it
near the top.
I would also like to
On Sunday, 18 December 2016 at 23:18:27 UTC, Andrei Alexandrescu
wrote:
Great, thanks. Please take a look at the accuracy of the
discussion. I expanded the "Workaround" section and moved it
near the top.
I would also like to register that while I respect your argument
regarding scalability,
On Monday, 19 December 2016 at 00:54:13 UTC, Andrei Alexandrescu
wrote:
On 12/18/16 7:44 PM, pineapple wrote:
On Sunday, 18 December 2016 at 23:18:27 UTC, Andrei
Alexandrescu wrote:
Great, thanks. Please take a look at the accuracy of the
discussion. I
expanded the "Workaround" section and
On Sunday, 18 December 2016 at 21:09:46 UTC, Andrei Alexandrescu
wrote:
On 12/18/2016 10:01 AM, pineapple wrote:
On Sunday, 18 December 2016 at 13:31:48 UTC, Andrei
Alexandrescu wrote:
Is the source code publicly available?
https://github.com/pineapplemachine/mach.d
The code looks clean,
On Sunday, 18 December 2016 at 23:18:27 UTC, Andrei Alexandrescu
wrote:
Great, thanks. Please take a look at the accuracy of the
discussion. I expanded the "Workaround" section and moved it
near the top.
https://github.com/dlang/DIPs/pull/51
On Sunday, 18 December 2016 at 13:31:48 UTC, Andrei Alexandrescu
wrote:
On 12/17/16 10:21 PM, pineapple wrote:
I am developing a general-use library for D that is currently
resting at
around 50,000 lines.
Is the source code publicly available?
https://github.com/pineapplemachine/mach.d
On Saturday, 24 December 2016 at 22:14:08 UTC, Andrei
Alexandrescu wrote:
https://github.com/dlang/druntime/pull/1724
Ho-ho-ho!
Andrei
Unacceptable. All breaking changes (Except the ones I create) are
evil.
On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko
wrote:
This thread is about mutiple values returned by _reference_.
Tuples can not do it, only pointers, but they are not ctfeable
and safe
The way to make this useful, if I'm understanding correctly,
would not be a more concise
On Friday, 23 October 2015 at 15:07:05 UTC, Alex Parrill wrote:
Use template mixins: http://dlang.org/template-mixin.html
On Friday, 23 October 2015 at 15:08:30 UTC, Adam D. Ruppe wrote:
Use a mixin template together with your interface.
Awesome, thanks!
No way, though, to unite
On Thursday, 22 October 2015 at 18:28:50 UTC, Ali Çehreli wrote:
If you already have a piece of memory, it is trivial to convert
it to a slice in D:
auto slice = existing_pointer[0 .. number_of_elements];
http://ddili.org/ders/d.en/pointers.html#ix_pointers.slice%20from%20pointer
The
Answered my own question: Turns out File.getFP() does exactly
what I needed
I'd like to use fread and fwrite in place of File.rawRead and
File.rawWrite which force the creation of an array where I'd
rather specify a buffer location and length. I'd like to do this
using a File object but the handle for the C stream is a private
member and I can't find any way to access
On Thursday, 22 October 2015 at 13:58:56 UTC, Adam D. Ruppe wrote:
D's templates are easy (you actually used one in there, the
Generator is one!)
Try this:
import std.concurrency;
Generator!T sequence(T)(T i){
return new Generator!T({
yield(i);
while(i > 1){
On Wednesday, 28 October 2015 at 11:40:14 UTC, tcak wrote:
The "writebuffer" is defined to take an array as parameter.
Yet, you are passing a pointer and a length to it. Instead,
pass the parameter "str" to it directly. Also, you do not have
to put "!char" to there. Compiler will solve it out
On Wednesday, 28 October 2015 at 12:06:14 UTC, Kagamin wrote:
On Wednesday, 28 October 2015 at 11:48:27 UTC, pineapple wrote:
There's also a writebuffer method in the interface with this
signature, though:
streamint writebuffer(T)(in T* buffer, in streamint count);
Interface can't have
When I attempt to compile my code I get the same linker error
with both dmd and ldc2. I know where the problematic code is, as
I don't get the error when I comment out lines 102 through 107,
but I don't understand why it's bad. I must have some
misconceptions about how templates work? Is there
Is it possible to have default method implementations in
interfaces à la Java in D? Or some equivalent that allows
multiple inheritance without a bunch of identical copypasted
method bodies?
I'm just starting to hammer D's very pleasant syntax into my
head. After "Hello world", the first thing I do when learning any
language is to write a simple program which generates and outputs
the Collatz sequence for an arbitrary number. (I also like to
golf it.) This is what I wrote in D:
On Thursday, 22 October 2015 at 14:36:52 UTC, John Colvin wrote:
Using ranges instead of threads or fibers, slightly
over-engineered to show off features:
What does if(isIntegral!T) do? It looks like it would verify that
the template type is a discrete number? If I were to create my
own
On Saturday, 4 June 2016 at 15:43:01 UTC, Mihail K wrote:
As far as I recall, foreach_reverse is deprecated in favour of
range operations.
ie.
import std.algorithm, std.range;
static if(forward)
{
items.each!(item => doStuff());
}
else
{
items.retro.each!(item =>
It would be fantastic if I could write this -
static if(forward){
foreach(item; items) dostuff();
}else{
foreach_reverse(item; items) dostuff();
}
as something like this -
foreach!forward(item; items) dostuff();
Is there any way to accomplish this?
On Wednesday, 25 May 2016 at 22:19:28 UTC, Seb wrote:
I know that writing your own library is fun, but something that
I see quite often when looking at e.g.
Yep, I saw a couple of those before I got started on mine. For
some of us it's a sense of ownership, I think. It feels good to
be
On Wednesday, 25 May 2016 at 22:29:38 UTC, pineapple wrote:
I will do that
...I'm honestly having second thoughts because reading the style
guide for phobos was like a watching a B horror movie.
All the code in the mach.d repo is very permissively licensed and
anyone with the patience to
A few weeks ago I made a github repo for D modules. I'm adding to
this as I learn the language, and as I find myself writing
modules to support other code.
https://github.com/pineapplemachine/mach.d
It hasn't got a lot at the moment, but it will grow for as long
as I'm writing D. I suspect
On Tuesday, 14 June 2016 at 07:35:36 UTC, Andrea Fontana wrote:
Simply:
method2();
Also, typeof(this).method2();
On Monday, 13 June 2016 at 22:54:13 UTC, Ali Çehreli wrote:
Tree!T tree(TL, T, TR)(TL left, T node, TR right) {
return new Tree!T(left, node, right);
}
There's also this:
Tree!T tree(TL, T, TR)(TL left, T node, TR right) if(
(is(TL == Tree!T) || is(TL == typeof(null))) &&
On Saturday, 28 May 2016 at 16:25:02 UTC, Seb wrote:
If you are interested how it works under the hood - it's pretty
simple & elegant:
I checked up on the phobos implementation and found that arrays
are mutated when iterated over as ranges, which didn't rest well
with me. Nor did the idea of
I found another post on this subject and the advice there was
"don't put const members in your structs" -
http://forum.dlang.org/thread/m87ln2$idv$1...@digitalmars.com
This doesn't work out so well when the templated struct is
referring to what happens to be a const array.
I thought I could
On Sunday, 29 May 2016 at 18:52:36 UTC, pineapple wrote:
What's the best way to handle something like this?
Well I did get something to work but it's ugly and I refuse to
believe there isn't a better way to handle this.
Where `Range` is an alias to a struct with an immutable member,
and
Here's one more vote for extending UFCS to operator overloading.
Elie wrote that it's "a restriction that seems pointless and
arbitrary"... which summarizes my own thoughts rather well, too.
There are certainly concerning scenarios that can arise from
making this change, but the correct way
On Monday, 30 May 2016 at 16:22:26 UTC, Max Samukha wrote:
From the spec (https://dlang.org/spec/function.html#nested):
"Nested functions cannot be overloaded."
Anybody knows what's the rationale?
I'm guessing it's related to -
Unlike module level declarations, declarations within function
I'd like to find the overload of some function with the most
parameters and (in this specific case) to get their identifiers
using e.g. ParameterIdentifierTuple. There have also been cases
where I'd have liked to iterate over the result of
Parameters!func for each overload of that function.
On Tuesday, 31 May 2016 at 20:46:37 UTC, Basile B. wrote:
Yes this can be done, you must use the getOverload trait:
https://dlang.org/spec/traits.html#getOverloads
The result of this trait is the function itself so it's not
hard to use, e.g the result can be passed directly to
'Parameters',
1 - 100 of 232 matches
Mail list logo
