yebblies: Can an auto-ref function pointer/deltegate implicitly
convert to ref?
9rnsr: To @yebblies : I yet not implement it because this is a
basic proposal.
IMHO, what he says is that behavior proposed by yebblies is some
more complicated special cases he is not going to do within this
You can use magic functions __ctor and __dtor which actually
serve as constructor and destructor implementations behind the
scene.
Example and proof-of-concept: http://dpaste.1azy.net/fd924332
Have no idea if it is explicitly defined by spec somewhere though.
On Wednesday, 23 January 2013 at 10:43:24 UTC, simendsjo wrote:
On Wednesday, 23 January 2013 at 10:30:08 UTC, Namespace wrote:
But AFAIK scope isn't fully implemented as storage class, or
am I wrong?
I think you are right. And I think it's the reason using 'in'
parameters are discouraged.
On Tuesday, 22 January 2013 at 09:29:07 UTC, Namespace wrote:
On Friday, 18 January 2013 at 13:13:03 UTC, Jacob Carlborg
wrote:
On 2013-01-18 14:07, Namespace wrote:
Despite the danger that this annoy you probably:
What about pull 1019
(https://github.com/D-Programming-Language/dmd/pull/1019)?
Do you want to discuss it? :) I have noticed that phobos style
guidelines favor constraints heavily over static asserts but this
exactly the example when I am uneasy about such choice: static
assert can both provide more user-friendly error message here and
remove some code duplication.
On
Hm, but why can't static assert provide an instantiation trace? I
can live without error message but duplicating same condition
twice (one time being part of implementation) hurts my eyes :(
On Monday, 21 January 2013 at 17:16:22 UTC, Ali Çehreli wrote:
On 01/21/2013 08:32 AM, mist wrote
On Monday, 21 January 2013 at 18:53:08 UTC, Ali Çehreli wrote:
...
Can you elaborate. I don't see the duplication.
Ali
First we check that parameter is one of allowed ones in
constraint. Then we do the very same check using the very same
operator list to actually make a right dispatch.
UDAs very design point is to never change type they are attached
to.
If you want to inject code in a class/struct at compile-time,
template mixins are supposed tools.
I thought template itself should compile but its statement-like
instantiation should not.
By the way, if all you want is to split out some generic
statement block without using dirty string mixins, template
functions with alias parameters may do.
I.e. http://dpaste.1azy.net/68ad8133
Don't
On Monday, 14 January 2013 at 10:13:16 UTC, Martin Drasar wrote:
On 14.1.2013 8:56, Maxim Fomin wrote:
Which compiler version do you use? It compiles on 2.061.
It was 2.060. It compiles now on 2.061. Great!
Yes, it was a known bug in pre-2.061
Big relief to have it working :)
It appears that you cannot mixin *any* statement with
scope([exit,success,etc]) in it.
I have been rereading my copy of TDPL, and it states that mixin
statements must be valid D code, and there can be multiple
'scope()'
statements.
Since scope(exit) writeln(); is valid D code, and refuses to
While working on
https://github.com/D-Programming-Language/phobos/pull/863 I have
noticed that inout breaks ParameterStorageClassTuple and family.
I have started working on a fix but quick comparison of
http://dlang.org/declaration.html#StorageClass vs
Meh, while I was looking for this info in docs kind Kenji simply
came out and fixed it, leaving no chance to learn :(
Do not have time to test code right now but first guess it is
related to parsing differences for delegates and usual functions.
Delegates can have shared/const applied to both delegate type
itself and context of underlying function. Those are different
beasts and no wonder type system
I basically want to be able to do stuff like this:
auto result = map!( (a, b) = a+b )( lockstep(range1, range2) );
Are there any standard short ways to wrap an input range around
struct with opApply (which Lockstep is)?
Also what about redesigning Lockstep as a proper range? I could
do a
Any objections to documentation update to cross-reference zip and
lockstep to each other? Was not even searching for first one when
found lockstep, huh.
On Saturday, 29 December 2012 at 14:19:39 UTC, Simen Kjaeraas
wrote:
On 2012-48-29 14:12, mist n...@none.none wrote:
I basically want
Not clever enough to expand like this though:
map!( (a, b) = a+b )( zip(Range1, Range2) );
Using a = a[0]+a[1] is not that big deal though.
On Saturday, 29 December 2012 at 17:58:55 UTC, Ali Çehreli wrote:
On 12/29/2012 06:19 AM, Simen Kjaeraas wrote:
foreach (a; zip(A, B) ) {
// Use a[0]
On Wednesday, 26 December 2012 at 00:47:28 UTC, Ali Çehreli wrote:
On 12/25/2012 04:13 PM, bearophile wrote:
Ali Çehreli:
I don't know the answer but this works:
That difference smells of compiler bug :-)
Bye,
bearophilee
Hmmm. I think the compiler is right. That const that is applied
http://dpaste.dzfl.pl/0cda8d0f
bug or feature?
On Tuesday, 23 October 2012 at 17:36:53 UTC, Simen Kjaeraas wrote:
On 2012-10-23, 19:21, mist wrote:
Hm, and all phobos functions should operate on narrow strings
as if they where not random-acessible? I am thinking about
something like commonPrefix from std.algorithm, which operates
on code
Actually it is awesome.
But all the code breakage.. eh.
Ok, just one question to make an official position clear: is
commonPrefix implementation buggy or it is a conscious decision
to go for some speed breaking correct operations on narrow
strings at the same time?
Thanks, that is exactly what I wanted to clarify.
Can I do pull request for this or do you plan to?
On Wednesday, 24 October 2012 at 12:03:10 UTC, Jonathan M Davis
wrote:
On Wednesday, October 24, 2012 13:39:50 Timon Gehr wrote:
You realize that the proposed solution is that arrays of code
units
would no longer be arrays of code units?
Yes and no. They'd be arrays of code units, but any
Wait. So you consider commonPrefix returning malformed string to
be fine? I have lost you here. For example, for code sample given
above, output is:
==
Пи
П[\D0]
==
Problem is if you use == on code unit you can match only part of
valid symbol.
Was thinking on this topic after seeing this:
http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d
Still can't understand rationale here. Why native slicing /
random access is allowed for narrow strings, but trait explicitly
negates this?
On Tuesday, 23 October 2012 at 15:55:23 UTC, Andrei Alexandrescu
wrote:
On 10/23/12 11:36 AM, mist wrote:
Was thinking on this topic after seeing this:
http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d
Still can't understand rationale here. Why native slicing
Hm, and all phobos functions should operate on narrow strings as
if they where not random-acessible? I am thinking about something
like commonPrefix from std.algorithm, which operates on code
points for strings.
On Sunday, 30 September 2012 at 21:34:36 UTC, Andrej Mitrovic
wrote:
On 9/30/12, jerro a...@a.com wrote:
I think this should work:
template returnsRef(alias f)
{
enum bool returnsRef = is(typeof(
{
ParameterTypeTuple!f param;
auto ptr = f(param);
}));
}
Yep.
How can I:
1) check if function returns by ref
2) check if function parameters are ref
..outside of function body. Is parsing typeof(func).stringof only
valid option?
Thanks!
Unfortunately, return type issue is more important in my case.
I'll check if implementation from ParameterStorageClassTuple can
be adapted for return types though.
On Sunday, 30 September 2012 at 20:37:14 UTC, Andrej Mitrovic
wrote:
On 9/30/12, mist n...@none.none wrote:
How can I
Thanks!
On Sunday, 30 September 2012 at 21:20:40 UTC, jerro wrote:
On Sunday, 30 September 2012 at 20:51:54 UTC, mist wrote:
Thanks!
Unfortunately, return type issue is more important in my case.
I'll check if implementation from ParameterStorageClassTuple
can be adapted for return types
Subject.
Is that possible? I see only parameter type tuple stuff out
there. I'm looking into iterating over own parameter name list
inside of function.
On Friday, 31 August 2012 at 19:15:14 UTC, Jacob Carlborg wrote:
On 2012-08-31 16:24, mist wrote:
Subject.
Is that possible? I see only parameter type tuple stuff out
there. I'm
looking into iterating over own parameter name list inside of
function.
Here: http://dlang.org/traits.html
Could you add more details here?
What is current official position? Updating typelist.d and
merging with typetuple.d? Keeping current one and rewriting some
algorithms from typelist to work with current TypeTuple?
My point is exactly that it is not that much important how such
library looks
Subj: http://dpaste.dzfl.pl/dfab7219
I wanted to code a small extension to phobos typetuple module to
extend basic available operations on type tuples more on par with
std.algorithm ones. I don't have enough practice in
metaprogramming D way though and would gladly listen any
recommendations
Ok, finally understood.
I was trying to declare hof like this: void f2( pure int
function() param ) , similar to the way I declare usual pure
functions. Looks like it is syntax error and only void f2( int
function() pure param ) is allowed. That led me to false
conclusion, that such
Actually, looks like you have done it already 2 years ago :)
http://d.puremagic.com/issues/show_bug.cgi?id=4505
Hello!
I have been asked few question recently from a Haskell programmer
about D2 and, after experimenting a bit, have found that I really
can't provide a good answe myself, as I am not getting a design
limititations (if any).
Here is the snippet, it is pretty self-descriptive:
But is there any way to actually say D compiler that I want this
function to accept only pure delegates?
40 matches
Mail list logo
