**I'm fairly new to D, so let me know if this belongs in another
thread.**
I'd like to contribute a new feature to the DMD front-end, and
I'd appreciate some feedback on the design before I start on a
pull request.
Feature:
`__traits(comment, symbol)` will evaluate to the
Thanks for the feedback!
On Tuesday, 6 May 2014 at 07:41:20 UTC, bearophile wrote:
Mason McGill:
Other implementations can choose to always evaluate it to .
Other implementations have to give the ddostring as well.
Good to know! This will simplify the entry in the Traits
documentation
On Tuesday, 6 May 2014 at 11:28:21 UTC, Chris wrote:
Maybe it's time to think about a D interface to Julia. If Julia
catches on within the scientific community, it would be good to
have a foot in the door. Science quickly creates large code
bases, unfortunately, so far it's mostly Python and
This is now a pull request:
https://github.com/D-Programming-Language/dmd/pull/3531
On Tuesday, 6 May 2014 at 21:00:18 UTC, bearophile wrote:
The language tries its best to be flexible as a dynamic
language. But variables never carry a run-time type tag, unlike
in Lisp.
Hmm... Then how can I do this:
x = 5
typeof(x) # evaluates to Int64
x = 5.0
typeof(x) # evaluates
On Wednesday, 7 May 2014 at 11:57:51 UTC, w0rp wrote:
Here is a question, is it possible for D, or any future
language, to eventually take something like this...
void foo(InputRange)(InputRange range)
if(isInputRange!InputRange);
...and to instead be able to write it like this?
void
On Friday, 9 May 2014 at 04:09:46 UTC, captaindet wrote:
by coincidence, i have use for this too. also thought
__traits(allMembers, ...) would work. too bad it doesn't. is
this a bug or expected behavior?
/det
Just out of curiosity, what's your use case?
On Saturday, 17 May 2014 at 01:53:46 UTC, Steven Schveighoffer
wrote:
A possible solution:
template interface isInputRange(T, E) { .. No change in
implementation .. }
void myTemplateFunction(T : isInputRange!int)(T t)
{
}
would basically change this into the equivalent of today's
On Saturday, 17 May 2014 at 18:03:53 UTC, Tolga Cakiroglu wrote:
After having some experience with documentation generation from
dmd command like, and seeing outputs, I wasn't satisfied with
it.
Other alternatives as Doxygen is available, though it parses
codes itself that is not based on what
On Friday, 30 May 2014 at 22:19:51 UTC, bearophile wrote:
A language solution is a literal syntax for fixed-sized arrays
(here I slice it again because unfortunately count doesn't
accept fixed-sized arrays):
immutable data = [1, 5, 3, 1, 5, 1, 5];
void main() @nogc {
import
I have a numerical/multimedia library that defines the concept of
an n-dimensional function sampled on a grid, and operations on
such grids. `InputGrid`s (analogous to `InputRange`s) can be
dense or sparse multidimensional arrays, as well the results of
lazy operations on other grids and/or
On Tuesday, 3 June 2014 at 22:05:29 UTC, TheFlyingFiddle wrote:
Well one reason for this is that unlike methods it is hard to
resolve ambiguity between diffrent operator overloads that have
been defined in diffrent modules.
Example: 2D-vectors
//vector.d
struct Vector
{
float x, y;
}
Interesting idea. I run into these sorts of bugs often doing
multimedia processing. There's definitely a tension between
writing generic code (NumPy-style, operating on abstract
dimensions) and safe code (operating on dimensions with
semantics; OpenCV supports this to an extent). I've never
On Wednesday, 4 June 2014 at 09:43:20 UTC, bearophile wrote
You can give strong typing to indexes of a matrix library, this
doesn't need language changes. So a dynamic array library in
Phobos could fulfil most of the possible desires or needs for
strongly typed indexes. But you lose some of
On Wednesday, 4 June 2014 at 18:46:04 UTC, Mason McGill wrote:
/* User code. */
import std.awesome_unit_library: Unit, of;
// Unit: defines new types that can be multiplied divided.
// of: wraps a container in a stricter version, enforcing
units.
alias Name = Unit!name;
alias
On Thursday, 5 June 2014 at 09:23:00 UTC, bearophile wrote:
Sorry for my answers coming so slowly.
Hah! I'm on these forums (selfishly) trying to understand/improve
D for my own use at work, while you seem to be
helping/teaching/contributing for the sake of it. I'm continually
surprised by
On Friday, 6 June 2014 at 20:22:35 UTC, Philippe Sigaud via
Digitalmars-d wrote:
Sorry to intrude, but you can also get:
enum newton = 1.kg/m/s^^2;
Good point. I actually learned D had an exponentiation operator
just yesterday. It definitely helps readability in this case.
On Thursday, 12 June 2014 at 15:00:20 UTC, Manu via Digitalmars-d
wrote:
I often find myself wanting to write this:
foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.
You can do this:
for(;;) {}
Good tutorial choices; they're very well-written. I haven't used
F# much, but here's my take (call me out on any mistakes in my
understanding):
`async` being just a particular instance of a class of
user/library-defined computation expression has a lot of good
things going for it. This setup
On Friday, 20 June 2014 at 22:01:31 UTC, Timon Gehr wrote:
On 06/20/2014 09:22 PM, Brian Schott wrote:
http://wiki.dlang.org/DIP64
Attributes in D have two problems:
1. There are too many of them and declarations are getting too
verbose
2. New attributes use @ and the old ones do not.
I've
On Sunday, 22 June 2014 at 05:18:05 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Sun, 22 Jun 2014 00:12:20 +
Mason McGill via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Attribute and property are pretty much synonyms in English,
and it always seemed strange to me that D had
On Thursday, 19 June 2014 at 23:41:25 UTC, H. S. Teoh via
Digitalmars-d wrote:
Pretty soon, we need an attribute algebra to express these
complicated
relationships.
It would be nice to have a solution that can handle all of
these cases
without exploding complexity in the syntax.
Here's one
On Monday, 23 June 2014 at 16:45:28 UTC, bearophile wrote:
I'm glad to hear there's interest in this! I've actually been
working on a generic multidimensional array library myself (on
and off) for the past few months (I'm hoping to have a
well-documented dub package by the end of the summer).
On Monday, 23 June 2014 at 20:34:59 UTC, Jonathan M Davis via
Digitalmars-d wrote:
It would be very cool if we could remove @ from all of the
built-in
attributes, but the whole reason that they have them in the
first place is
because it was decided that we didn't want to add new keywords
- and
On Monday, 23 June 2014 at 21:33:40 UTC, H. S. Teoh via
Digitalmars-d wrote:
You are far from the first one to write a multidimensional
array library
in D. Denis has already done this some time ago, and I have,
too.
I've seen Denis' library. It seems nice, but it's a lot more
concrete that
On Tuesday, 24 June 2014 at 04:36:04 UTC, ed wrote:
On Monday, 23 June 2014 at 21:08:03 UTC, Mason McGill wrote:
[snip]
Concepts:
InputGrid: anything with a size (size_t[n]) and n-dimensional
opIndex.
OutputGrid: anything with a size (size_t[n]) and
n-dimensional opIndexAssign.
[snip]
I like DIP54 and I think the work on fixing tuples is awesome,
but I have 1 nit-picky question: why is it called
TemplateArgumentList when it's not always used as template
arguments?
void func(string, string) { }
TypeTuple!(string, string) var;
var[0] = I'm nobody's ;
var[1] =
On Saturday, 28 June 2014 at 09:15:29 UTC, Dicebot wrote:
On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
I like DIP54 and I think the work on fixing tuples is awesome,
but I have 1 nit-picky question: why is it called
TemplateArgumentList when it's not always used as template
On Saturday, 28 June 2014 at 21:12:06 UTC, Timon Gehr wrote:
On 06/28/2014 06:11 PM, Mason McGill wrote:
On Saturday, 28 June 2014 at 09:15:29 UTC, Dicebot wrote:
On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
I like DIP54 and I think the work on fixing tuples is
awesome, but I
On Monday, 23 June 2014 at 08:30:44 UTC, h_zet wrote:
import std.typecons;
auto foo2(R)(R foopara){
return tuple(foopara, is(R==int));
}
void main(){
auto tuple(a,b) = foo2(1);
}
I'm expecting some error such as can not act as left value but
when I compiled this, no error occured.
On Monday, 23 June 2014 at 09:29:15 UTC, Mason McGill wrote:
Strange behavior, indeed. It took me a minute, but I think I
know what's going on, and I'm pretty sure it's a bug. D
recently introduced a short syntax for function-like templates:
enum a(b) = some_value;
It looks like this also
31 matches
Mail list logo
