On Monday, 31 December 2012 at 02:47:46 UTC, Jonathan M Davis
wrote:
3. Create a new attribute which has to be used when a function
returns a ref
to a parameter and use that to make it illegal to pass a ref to
a local
variable to such functions.
If this is the way to go, maybe "@saferef" co
On Sunday, 30 December 2012 at 08:38:27 UTC, Jonathan M Davis
wrote:
And maybe another solution which I can't think of at the moment
would be
better. But my point is that we currently have a _major_ hole
in SafeD thanks
to the combination of ref parameters and ref return types, and
we need to f
On Sunday, 30 December 2012 at 22:02:16 UTC, Jonathan M Davis
wrote:
The closest that we could get to what you suggest would be to
add a new
attribute similar to nothrow but which guarantees that the
function does not
return a ref to a parameter. So, you'd have to mark your
functions that way
(
I wrote this article because I felt like helping other people coming to
D, but I'm not sure where the appropriate place to make such a
contribution is. Maybe a "Learning Articles" or an "Idioms" section.
The One-Letter Nested Function
As a programmer new to D I wanted to share an idiom I've be
On 2/13/12 9:14 AM, bearophile wrote:
Where possible it's good to add "static" to nested functions:
static ubyte u(in int a, in int b) pure nothrow { return cast(ubyte)
uniform(a,b); }
You're right. The only advantage to the way I wrote it is, possibly,
it's easier for new people (like mys
On 2/10/12 4:04 PM, Andrei Alexandrescu wrote:
The last thing we need is balkanization of the community. You are of
course free to initiate such a project but if you care about D it would
be great to apply your talent in a different direction.
I think this might be going a little bit too far.
On 2/13/12 11:21 AM, bearophile wrote:
Zach the Mystic:
Regarding pure random generators, I have asked it too:
http://d.puremagic.com/issues/show_bug.cgi?id=5249
Aren't "pure" and "random" diametrically opposed in a fundamental way?
On 2/13/12 11:54 AM, Andrei Alexandrescu wrote:
I just find it difficult to imagine things that way. Tiny devices are
confined to small programs by definition, and at that magnitude the
field is quite leveled; for a 3K-lines program, C is just fine and many
of D's (and other languages') advantage
On 2/13/12 1:17 PM, Andrei Alexandrescu wrote:
Agreed. There are two issues I see here in my opinion. First, putting
some of our manpower in a small subset of D for tiny embedded systems is
a misplaced investment because it would make a small impact at best.
Second, coming up with another D-deriv
I would like the authors of all the pages accessible by the
"Articles" link to be given credit for their writings. It's
inconsistent because some have their author listed and others
don't.
These are a few which have no author listed:
http://dlang.org/exception-safe.html
http://dlang.org/hijack
On Friday, 4 January 2013 at 20:20:08 UTC, Jonathan M Davis wrote:
... But it doesn't change the
statement that a function which takes a parameter by ref and
returns by ref
can't be considered @safe without additional constraints of
some kind. It just
shows why you don't have an easy way out to
I've here formalized how I think the constraints on a non-scope
ref taking and ref returning function should work. This
represents a whole addition to the type system. The attribute
"@outref" from my previous post has been shortened to keyword
"out" (must come before parentheses). This is all I
Here are my two cents:
First, about optional parentheses:
Optional parentheses = ambiguity.
int foo() { return 4; }
auto x = foo; // gives 4 or gives function foo?
It seems to me any ambiguity should be an error. However… it only
matters when the type system can't provide the missing detail,
On Friday, 25 January 2013 at 22:02:06 UTC, Timon Gehr wrote:
On 01/25/2013 10:44 PM, Zach the Mystic wrote:
Here are my two cents:
First, about optional parentheses:
Optional parentheses = ambiguity.
...
No, you can definitely have ambiguity without optional
parentheses.
Unless that is
On Saturday, 26 January 2013 at 00:47:38 UTC, Zach the Mystic
wrote:
That is not ambiguous.
But this time *your* comment is ambiguous! If you mean my
*statement* is not ambiguous, then yes.
Actually, that's ambiguous too. My English language statement.
On Sunday, 27 January 2013 at 02:54:55 UTC, Adam D. Ruppe wrote:
It would be cool if we could declare variables with anonymous
types;
struct { opAssign() {} } foo;
This would be much easier to understand:
alias foo struct { opAssign() {} };
Is "singleton structures", a.k.a. properties, a go
On Sunday, 27 January 2013 at 05:32:25 UTC, Zach the Mystic wrote:
On Sunday, 27 January 2013 at 02:54:55 UTC, Adam D. Ruppe wrote:
It would be cool if we could declare variables with anonymous
types;
struct { opAssign() {} } foo;
This would be much easier to understand:
alias foo struct
Several suggestions here:
With regard to optional parentheses, it had been suggested that
any ambiguity be regarded as an error. This is the example I used:
int foo() { return 4; }
auto x = foo; // Error: gives 4 or gives function foo?
I suggested the ambiguity be resolved thus:
auto x = foo
On Sunday, 27 January 2013 at 21:03:45 UTC, Maxim Fomin wrote:
int foo() { return 4; }
auto x = foo; // Error: gives 4 or gives function foo?
Unlike C, in D a function is not implicitly converted to
pointer to function, and because you cannot create functions as
stack variables, that statemen
On Sunday, 27 January 2013 at 23:29:16 UTC, Timon Gehr wrote:
In the absence of language rules, every sequence of characters
has an ambiguous meaning. It is only ambiguous to you because
you seem not aware of the rule that states that free-standing
function names are an alternative notation for
On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu
wrote:
I was thinking of just using &foo, like in C.
BTW also regarding optional parentheses, while I was working on
https://github.com/D-Programming-Language/tools/pull/41/files I
refactored a bit of code to use UFCS and paren-le
On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu
wrote:
BTW also regarding optional parentheses, while I was working on
https://github.com/D-Programming-Language/tools/pull/41/files I
refactored a bit of code to use UFCS and paren-less syntax. I
must say I find this a very fluid
On Monday, 28 January 2013 at 04:42:34 UTC, Andrei Alexandrescu
wrote:
Do you think the Ferrari (i.e. optional parens) has got
what it needs under the hood?
I'm not sure I understand the question.
Just that the elegant appearance of UFCS and optional parens
isn't offset underneath by built-
On Monday, 28 January 2013 at 08:34:53 UTC, Jacob Carlborg wrote:
On 2013-01-28 03:25, Zach the Mystic wrote:
I first saw UFCS and optional parentheses in Ruby and it
seemed both
alluring and deceptively simple.
First, Ruby doesn't have UFCS. You can add a new method to any
existing
On Monday, 28 January 2013 at 03:24:09 UTC, Steven Schveighoffer
wrote:
There are three intentions when creating a function w/ regards
to properties:
1. You intend the function to be called without parentheses to
clarify it is a property.
2. You intend the function to be only called with paren
Steven Schveighoffer had mentioned the interesting point that you
may want *mandate* the use of parentheses. This is easily
solvable with another opXXX function, which I name opDo. Just to
illustrate with ordinary structs:
struct Foo
{
int opDo() { return 4; }
}
Foo foo;
foo; // Error: a st
On Saturday, 26 January 2013 at 13:38:06 UTC, Andrei Alexandrescu
wrote:
Hello,
This is the last weekend before the submission deadline on
Monday. This is the time to act! Remember, at this time we only
need the title, abstract, and bio - no article or slides.
I know that I'm very new here,
Just for kicks I decided to rewrite std.array.front in the way my
suggested syntax would define it. there are two overloads. With
comments removed, the current code is:
// Code
@property ref T front(T)(T[] a)
if (!isNarrowString!(T[]) && !is(T[] == void[]))
{
assert(a.length, "Atte
Sorry if the code comes across funny in the browser. It looked
fine in the window I typed it in. ^_^
If the phobos designers wanted lax property enforcement, they
could of course use opCall instead of opGet.
On Monday, 28 January 2013 at 18:17:31 UTC, Zach the Mystic wrote:
Steven Schveighoffer had mentioned the interesting point that
you may want *mandate* the use of parentheses.
If you absolutely must have parens and my Highlander structs are
a no go for whatever reason, you could just have
On Tuesday, 29 January 2013 at 18:54:09 UTC, H. S. Teoh wrote:
I agree with all of this, except that currently, as things
stand, we
can't actually implement certain kinds of properties as
structs, because
nested structs do not have access to their parent lexical scope:
class Rectangle
On Tuesday, 29 January 2013 at 17:47:44 UTC, Rob T wrote:
The struct property concept is perhaps more profound than the
function-only approach because it can be used for much more
than what was originally intended, For example, any normal
variable can be redefined into a property, allowing you
On Tuesday, 29 January 2013 at 21:32:00 UTC, Rob T wrote:
Zach the Mystic mentions a situation where we wrap not the
data, but only the functions around a struct-like property
object, that way it contains no data of its own, does not need
a "this" or a constructor or destructor
On Wednesday, 30 January 2013 at 01:09:12 UTC, H. S. Teoh wrote:
As for using struct to implement @property, I like the idea,
but it does
raise tricky issues about how struct methods reference the
parent
lexical scope. I don't think it's as simple as just rewriting
'this' to
point to the outer
On Wednesday, 30 January 2013 at 01:20:39 UTC, Zach the Mystic
wrote:
On Wednesday, 30 January 2013 at 01:09:12 UTC, H. S. Teoh wrote:
There's also the consideration of what happens if you take the
address
of the 'pseudo' variable: the inner struct would then be
effectively
d
On Tuesday, 29 January 2013 at 21:23:19 UTC, Rob T wrote:
We can extend the idea to not only think in terms of "smart
data", but also in terms of "smart processing", where a normal
function is wrapped up into a struc like object so that it may
optionally carry it's own data for holding state, a
On Tuesday, 29 January 2013 at 18:54:09 UTC, H. S. Teoh wrote:
I agree with all of this, except that currently, as things
stand, we
can't actually implement certain kinds of properties as
structs, because
nested structs do not have access to their parent lexical scope:
class Rectangle
On Wednesday, 30 January 2013 at 05:20:51 UTC, Zach the Mystic
wrote:
You know, I was too dumb to even understand what you wrote when
I read it the first time. I was just naively assuming that
nested structs were like nested functions. Some rules
definitely need to be figured out here. I don&#
On Wednesday, 30 January 2013 at 05:30:47 UTC, Zach the Mystic
wrote:
I'm sorry for missing your point. I'm trying to suggest
advanced language features without even knowing some of the
basics. I ask you to bear with me.
Wait, hold on there! This says otherwise:
http://dlang.org/s
On Wednesday, 30 January 2013 at 05:24:56 UTC, Zach the Mystic
wrote:
On Wednesday, 30 January 2013 at 05:20:51 UTC, Zach the Mystic
wrote:
You know, I was too dumb to even understand what you wrote
when I read it the first time. I was just naively assuming
that nested structs were like nested
On Tuesday, 29 January 2013 at 18:54:09 UTC, H. S. Teoh wrote:
class Rectangle {
float width, height;
// Struct implementation of @property
struct AreaProp {
float value() {
// Error:
On Wednesday, 30 January 2013 at 06:46:01 UTC, H. S. Teoh wrote:
That page only states the structs nested inside *functions*
have a
context pointer to the function's local variables. It says
nothing about
structs nested inside *structs*. (And yes, I looked. I was
actually in
the middle of writ
On Wednesday, 30 January 2013 at 06:38:32 UTC, Rob T wrote:
opCall requires parens, probably to disambiguate from alias
this.
string A
{
int i;
int opCall() { return _i; }
}
A a,
int i = a; // error
int i = a(); // works
You can however do this
alias opCall this;
int i = a; // works
in
On Wednesday, 30 January 2013 at 17:35:25 UTC, Dmitry Olshansky
wrote:
2) How much code
breakage?
A lot + subtly wasting memory.
I still have to read your other comments, but the issue of
wasting memory has already been addressed by suggesting that the
compiler detect that absence of any ac
On Wednesday, 30 January 2013 at 17:42:48 UTC, TommiT wrote:
On Wednesday, 30 January 2013 at 17:02:44 UTC, Zach the Mystic
wrote:
[..] 1) How hard to implement structs nested in structs to
mimic ones nested in functions?
Given:
struct Outer {
struct Inner {
int n1;
}
int
On Wednesday, 30 January 2013 at 17:35:25 UTC, Dmitry Olshansky
wrote:
Okay, cool. Two questions remain: 1) How hard to implement
structs
nested in structs to mimic ones nested in functions?
IMO if property is to be implemented in the library it has to
include the field itself. (And I suspec
On Wednesday, 30 January 2013 at 18:36:17 UTC, Dmitry Olshansky
wrote:
I have one key problem - the hidden pointer detail.
In other words how should it find the instance of the outer
struct to to access it?
struct A{
int a;
struct B{
void foo(){ a = 42; }
On Wednesday, 30 January 2013 at 19:44:43 UTC, TommiT wrote:
On Wednesday, 30 January 2013 at 18:05:08 UTC, Zach the Mystic
wrote:
[..]
How about using this new namespace_thingy keyword:
struct S
{
private int value;
namespace_thingy prop
{
int get() { return value
On Wednesday, 30 January 2013 at 21:41:58 UTC, Zach the Mystic
wrote:
But what if B actually had some data? The only solution is to
have one pointer for every struct it's nested inside of. I can
imagine it getting tricky in this case. If it were so tricky as
to be prohibitive to impl
On Wednesday, 30 January 2013 at 22:30:10 UTC, TommiT wrote:
On Wednesday, 30 January 2013 at 21:58:53 UTC, Zach the Mystic
wrote:
Also, because the "namespace_thingy"s have so much in common
with structs, I think it would be misleading to call them
something else.
The problem of u
On Tuesday, 29 January 2013 at 19:21:34 UTC, Walter Bright wrote:
Even worse is all the millions of man-hours wasted in (usually
incorrectly) trying to make C code portable to theoretical C
compilers that have ints larger than 32 bits, etc., trying to
ensure that modern C code will work on a 16
On Thursday, 31 January 2013 at 00:50:39 UTC, H. S. Teoh wrote:
On Thu, Jan 31, 2013 at 01:36:06AM +0100, Zach the Mystic wrote:
On Tuesday, 29 January 2013 at 19:21:34 UTC, Walter Bright
wrote:
>Even worse is all the millions of man-hours wasted in (usually
>incorrectly) trying to make
On Thursday, 31 January 2013 at 01:26:19 UTC, Steven
Schveighoffer wrote:
The compromise is: OK, you want to ditch @property? I can live
with that as long as we have some way to designate properties.
How about this?
It's only natural that a person wants to advocate for his or her
own propos
On Thursday, 31 January 2013 at 01:14:36 UTC, TommiT wrote:
Here's Bjarne Stroustrup's reasoning for this design choice
http://www.stroustrup.com/bs_faq2.html#sizeof-empty
Q: Why is the size of an empty class not zero?
A: To ensure that the addresses of two different objects will
be different.
On Wednesday, 30 January 2013 at 21:41:58 UTC, Zach the Mystic
wrote:
On Wednesday, 30 January 2013 at 18:36:17 UTC, Dmitry Olshansky
wrote:
I have one key problem - the hidden pointer detail.
In other words how should it find the instance of the outer
struct to to access it?
struct A
On Thursday, 31 January 2013 at 12:44:18 UTC, TommiT wrote:
On Thursday, 31 January 2013 at 03:35:32 UTC, Zach the Mystic
wrote:
Now classes are a different kettle of fish.
Sorry for not being more explicit. Bjarne Stroustrup is the
creator of C++, so the Q&A I posted refers to C++, n
On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
I'm not sure that we can solve this without addressing the
high-level question: What is the scope of Phobos?
How big will it eventually get? Twice its current size? Ten
times? A hundred times?
Purely by chance I read an article on the
e the books on this issue
without even *examining* my proposal, found here:
http://forum.dlang.org/thread/kdukid$stg$1...@digitalmars.com?page=2#post-yqvrjszzlcpmmuyqyxdz:40forum.dlang.org
If you want the main points, just read all of the posts by Zach
the Mystic. I've done my best to defend
On Thursday, 31 January 2013 at 19:13:03 UTC, Zach the Mystic
wrote:
Here's the most concise quote which gives you the gist of the
thing:
"Now classes are a different kettle of fish. I haven't thought
them out and I don't think I need to. They may work seamlessly
with m
On Thursday, 31 January 2013 at 15:40:19 UTC, Michel Fortin wrote:
On 2013-01-31 14:50:40 +, "Steven Schveighoffer"
said:
It actually is a bit depressing, we have to reset the clock
back to late 2009 to start over with properties...
I haven't participated in the discussions about prope
On Thursday, 31 January 2013 at 20:52:39 UTC, Steven
Schveighoffer wrote:
I'm hoping that the community won't close the books on this
issue without even *examining* my proposal, found here:
http://forum.dlang.org/thread/kdukid$stg$1...@digitalmars.com?page=2#post-yqvrjszzlcpmmuyqyxdz:40forum.dl
On Thursday, 31 January 2013 at 22:54:21 UTC, Steven
Schveighoffer wrote:
C# has properties like this:
property int foo {
get {return _foo;}
set {_foo = value;}
}
Your proposal looks like this:
foo struct {
int opGet() {return _foo;}
void opSet(int value) {_foo = value;}
}
What I se
On Friday, 1 February 2013 at 01:53:05 UTC, TommiT wrote:
On Friday, 1 February 2013 at 00:59:47 UTC, Zach the Mystic
wrote:
writeln(foo.n); // uses alias this to call __mightAsWellBeOpGet
No it won't. It will print "n()".
And that exactly (passing to a templated pa
On Friday, 1 February 2013 at 01:53:05 UTC, TommiT wrote:
On Friday, 1 February 2013 at 00:59:47 UTC, Zach the Mystic
wrote:
writeln(foo.n); // uses alias this to call __mightAsWellBeOpGet
No it won't. It will print "n()".
And that exactly (passing to a templated pa
On Friday, 1 February 2013 at 02:27:30 UTC, TommiT wrote:
And here's another example of why it is as big of a problem as
I make it sound to be:
import std.concurrency;
struct Array
{
int _len;
length struct // Using Zach's syntax
{
@property get() { return _len; }
On Friday, 1 February 2013 at 03:08:12 UTC, Zach the Mystic wrote:
On Friday, 1 February 2013 at 01:53:05 UTC, TommiT wrote:
On Friday, 1 February 2013 at 00:59:47 UTC, Zach the Mystic
wrote:
writeln(foo.n); // uses alias this to call
__mightAsWellBeOpGet
No it won't. It will pri
On Friday, 1 February 2013 at 03:12:29 UTC, TommiT wrote:
On Friday, 1 February 2013 at 02:52:42 UTC, Zach the Mystic
wrote:
I need to study this principle a little more. In other words,
alias this is a templated parameter in this case? Which page
is the documentation for these templated
On Friday, 1 February 2013 at 03:28:05 UTC, TommiT wrote:
On Friday, 1 February 2013 at 03:08:12 UTC, Zach the Mystic
wrote:
alias template theFuncIActuallyWant this;
int theFuncIActuallyWant() { return 1; }
...in order to have it pass the right thing to the template
parameter? That's j
On Friday, 1 February 2013 at 03:33:05 UTC, Zach the Mystic wrote:
On Friday, 1 February 2013 at 03:28:05 UTC, TommiT wrote:
On Friday, 1 February 2013 at 03:08:12 UTC, Zach the Mystic
wrote:
alias template theFuncIActuallyWant this;
int theFuncIActuallyWant() { return 1; }
...in order to
On Friday, 1 February 2013 at 03:39:19 UTC, TommiT wrote:
On Friday, 1 February 2013 at 03:13:42 UTC, Zach the Mystic
wrote:
On Friday, 1 February 2013 at 02:27:30 UTC, TommiT wrote:
And here's another example of why it is as big of a problem
as I make it sound to be:
import std.concur
On Friday, 1 February 2013 at 03:44:51 UTC, TommiT wrote:
On Friday, 1 February 2013 at 03:23:09 UTC, Zach the Mystic
wrote:
I think it might mean "it is used" since I don't know why it
would use "is" instead of the opCast. If that's true, just
override opCa
On Friday, 1 February 2013 at 04:33:05 UTC, Steven Schveighoffer
wrote:
On Thu, 31 Jan 2013 19:59:46 -0500, Zach the Mystic:
This is not some kind of special property implementation. n is
a struct. It has no data and therefore is a very peculiar kind
of struct. A struct with no data needs only
On Friday, 1 February 2013 at 06:52:32 UTC, Zach the Mystic wrote:
FYI, nested structs in functions (the ones you want to use as
a model) have an extra hidden reference pointer back to the
stack frame data. That is how they can access the local
variables of the function.
Yeah, see, the
On Friday, 1 February 2013 at 15:29:38 UTC, Steven Schveighoffer
wrote:
On Fri, 01 Feb 2013 01:52:29 -0500, Zach the Mystic
wrote:
On Friday, 1 February 2013 at 04:33:05 UTC, Steven
Schveighoffer wrote:
No, the struct must have data. If it doesn't, how does it
get back to the owner
On Friday, 1 February 2013 at 16:24:53 UTC, Michel Fortin wrote:
On 2013-02-01 15:54:14 +, "Zach the Mystic"
said:
And there is simply no need for a data-less struct to allow a
"this" pointer. There will never be any need to know the
address of a data-less struct
On Friday, 1 February 2013 at 17:23:45 UTC, Rob T wrote:
I've had to step away from this for a while, but I want to say
that I don't see a problem with the data-less "struct" property
idea at all, although calling it a struct is perhaps causing
some confusion because real structs tend to host i
On Friday, 1 February 2013 at 18:34:01 UTC, Steven Schveighoffer
wrote:
I think you are wrong in how you assume a struct works, but not
in your attempt to implement properties. Struct is just not a
key to this formula.
I disagree. It is absolutely the fundamental key to this formula.
Note th
On Friday, 1 February 2013 at 19:59:12 UTC, Steven Schveighoffer
wrote:
On Fri, 01 Feb 2013 14:17:00 -0500, Zach the Mystic
wrote:
On Friday, 1 February 2013 at 18:34:01 UTC, Steven
Schveighoffer wrote:
I think you are wrong in how you assume a struct works, but
not in your attempt to
On Friday, 1 February 2013 at 21:33:31 UTC, Rob T wrote:
It's one thing to implement a struct, and another thing to
implement nested structs that can refer to the host instance. I
know some people want nested structs that can work in that way,
but implementation is problematic because when the
On Saturday, 2 February 2013 at 03:14:30 UTC, Zach the Mystic
wrote:
On Friday, 1 February 2013 at 21:33:31 UTC, Rob T wrote:
It's one thing to implement a struct, and another thing to
implement nested structs that can refer to the host instance.
I know some people want nested structs tha
On Thursday, 31 January 2013 at 19:04:05 UTC, H. S. Teoh wrote:
On Thu, Jan 31, 2013 at 07:53:58PM +0100, Zach the Mystic wrote:
On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
>I'm not sure that we can solve this without addressing the
>high-level question: What is the scop
On Thursday, 31 January 2013 at 19:04:05 UTC, H. S. Teoh wrote:
Interesting. I think Phobos can be easily divided into two
parts, with
core stuff like std.algorithm, std.range, std.stdio, etc., in
one, and
less common but still widely applicable stuff like numeric
algorithms in
a "2nd party" l
On Saturday, 2 February 2013 at 06:04:01 UTC, TommiT wrote:
On Saturday, 2 February 2013 at 03:50:49 UTC, Zach the Mystic
wrote:
assert(A.B.C.myMemberFunction(a, a.b, a.b.c) == 3);
That wouldn't compile, so you must mean:
assert(a.b.c.myMemberFunction(a, a.b, a.b.c) == 3);
You'r
On Saturday, 2 February 2013 at 07:10:00 UTC, TommiT wrote:
On Saturday, 2 February 2013 at 03:50:49 UTC, Zach the Mystic
wrote:
[..]
Then, if we used your proposed nested structs to implement
properties, pretty weird things like this would become possible:
struct A
{
int _value
On Saturday, 2 February 2013 at 06:28:47 UTC, Era Scarecrow wrote:
It would refuse to compile as a static function can't point to
an instance/parent. I'm convinced you should not be able to
return (or create an instance of) a nested struct outside of
it's level of control or ability to referen
On Saturday, 2 February 2013 at 06:19:29 UTC, TommiT wrote:
On Saturday, 2 February 2013 at 03:50:49 UTC, Zach the Mystic
wrote:
[..]
What do you suppose would happen if I wrote the following?
struct A
{
struct B {}
B b1;
B b2;
}
void main()
{
A a;
assert(&a.b1 == &
On Saturday, 2 February 2013 at 06:28:47 UTC, Era Scarecrow wrote:
On Saturday, 2 February 2013 at 06:04:01 UTC, TommiT wrote:
What do you suppose would happen if I wrote the following?
struct A
{
static int otherFunction()
{
C cc;
return cc.myMemberFunction();
}
It wo
On Saturday, 2 February 2013 at 17:33:38 UTC, TommiT wrote:
I was simply using A.B.C.myMemberFunction as a shorthand for
whatever name the compiler uses underneath the hood to
represent the non-static version of the function.
Yes, I can see that now. I didn't understand that the code
wasn't a
On Saturday, 2 February 2013 at 18:47:37 UTC, TommiT wrote:
On Saturday, 2 February 2013 at 17:56:41 UTC, Zach the Mystic
wrote:
On Saturday, 2 February 2013 at 06:19:29 UTC, TommiT wrote:
On Saturday, 2 February 2013 at 03:50:49 UTC, Zach the Mystic
wrote:
[..]
What do you suppose would
On Saturday, 2 February 2013 at 20:30:26 UTC, Era Scarecrow wrote:
On Saturday, 2 February 2013 at 18:03:32 UTC, Zach the Mystic
wrote:
On Saturday, 2 February 2013 at 06:28:47 UTC, Era Scarecrow
It would refuse to compile as a static function can't point
to an instance/parent. I'm
On Sunday, 3 February 2013 at 03:34:23 UTC, Era Scarecrow wrote:
Agreed 100%, Although a second (instance of) Dog may want to
come about and them sniff tails. That's outside access, but
it's still within the limits of the Dogs. In those cases a
context pointer could be acceptable as long as it
On Sunday, 3 February 2013 at 03:15:57 UTC, TommiT wrote:
On Sunday, 3 February 2013 at 02:55:44 UTC, Zach the Mystic
wrote:
Well, if you want access to a struct from outside, save
yourself the time and put it outside to begin with. A nested
struct of course is directly related to the entity
On Sunday, 3 February 2013 at 07:33:52 UTC, Zach the Mystic wrote:
On Sunday, 3 February 2013 at 03:15:57 UTC, TommiT wrote:
On Sunday, 3 February 2013 at 02:55:44 UTC, Zach the Mystic
wrote:
Well, if you want access to a struct from outside, save
yourself the time and put it outside to begin
On Monday, 4 February 2013 at 22:17:04 UTC, Era Scarecrow wrote:
On Monday, 4 February 2013 at 14:37:29 UTC, Dicebot wrote:
Nested types with hidden context pointers is one of D features
I do not like at all.
Please leave me at least my structs. :(
They already exist for classes though; Or s
On Friday, 1 February 2013 at 19:59:12 UTC, Steven Schveighoffer
wrote:
Well, we can disagree, but you still haven't explained why it's
fundamental. Other languages have implemented properties just
fine without having to specify that they are structs or
aggregate types. Until you come up with
Introduction:
A somewhat heated discussion between Steven Schveighoffer and
myself led to his challenging me to show not only how properties
could be implemented as structs, but also why that is the best
way for D to implement them.
The challenge is to do better, both in terms of functionali
On Tuesday, 5 February 2013 at 01:41:23 UTC, Marco Leise wrote:
Just one note on your Sparky example (from the ASM point of
view): Instead of passing in a pointer to each struct member
(wagTheDog(sparky, sparky.bodi, sparky.bodi.tail);) you could
pass in only 'sparky' as the rest are known offset
On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu
wrote:
Walter and I have had a discussion on how to finalize
properties.
http://wiki.dlang.org/DIP23
We got input from DIP21 (which we didn't want to clobber, hence
the new DIP) and the recent discussion.
The proposal probably
On Tuesday, 5 February 2013 at 08:39:15 UTC, Dmitry Olshansky
wrote:
On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13
2:04 PM, Jonathan M Davis wrote:
>> We could save a lot of boilerplate code if we can simply
make it
>> variables and
>> property functions guaranteed to be swappabl
1 - 100 of 465 matches
Mail list logo
