On Wednesday, 6 February 2013 at 21:35:12 UTC, MattCoder wrote:
On Wednesday, 6 February 2013 at 13:16:45 UTC, Paulo Pinto
wrote:
I just wanted to show that the pointer tricks for memory
management are not an exclusivity from C and C++.
I get it! Just one more note, would you have done any
On 2/7/2013 12:34 PM, Andrej Mitrovic wrote:
What do you mean by design win? You mean we'd win another company over to D?
Yes (for a project of theirs).
On 2/7/13, Walter Bright newshou...@digitalmars.com wrote:
On 2/7/2013 12:34 PM, Andrej Mitrovic wrote:
What do you mean by design win? You mean we'd win another company over
to D?
Yes (for a project of theirs).
Can you give us a teaser on generally what kind of work they do?
On Thursday, 7 February 2013 at 20:16:03 UTC, Walter Bright wrote:
No, I can't say who it is at this time. Sorry. But it is a huge
opportunity for us.
This is nice.
To get the design win, we need to:
(a) get dynamic linking and loading to work
Wasn't this realized before? By the way, last
On 2/7/2013 1:01 PM, Maxim Fomin wrote:
I guess recent patches dedicated to the issue came at right time.
The timing is indeed fortuitous.
As for your comments about vagueness, yes, it is vague. The DLL support is
clear, though, it either works or it doesn't. The other issues are a work in
On Thursday, 7 February 2013 at 21:11:18 UTC, Walter Bright wrote:
On 2/7/2013 1:01 PM, Maxim Fomin wrote:
I guess recent patches dedicated to the issue came at right
time.
The timing is indeed fortuitous.
As for your comments about vagueness, yes, it is vague. The DLL
support is clear,
Am 07.02.2013 22:11, schrieb Walter Bright:
On 2/7/2013 1:01 PM, Maxim Fomin wrote:
I guess recent patches dedicated to the issue came at right time.
The timing is indeed fortuitous.
As for your comments about vagueness, yes, it is vague. The DLL support
is clear, though, it either works
On Thursday, 7 February 2013 at 20:16:03 UTC, Walter Bright wrote:
No, I can't say who it is at this time. Sorry. But it is a huge
opportunity for us.
To get the design win, we need to:
(a) get dynamic linking and loading to work
(b) improve language safety without degrading efficiency
(c)
Am Thu, 07 Feb 2013 22:01:10 +0100
schrieb Maxim Fomin ma...@maxim-fomin.ru:
On Thursday, 7 February 2013 at 20:16:03 UTC, Walter Bright wrote:
(a) get dynamic linking and loading to work
Wasn't this realized before? By the way, last weeks there seems
to be increasing dynamic linking
On 2/7/2013 10:36 PM, Oleg Kuporosov wrote:
That is cool, but what is the target platform - Win/Lin, 32/64?
Initially, Linux. Once that is worked out, doing the others should be
straightforward.
On Thursday, 7 February 2013 at 07:41:57 UTC, Johannes Pfau wrote:
Am Wed, 06 Feb 2013 23:45:51 +0100
schrieb Robert jfanati...@gmx.at:
What happened to the scope storage class for parameters.
Wouldn't this solve the problems, with the simple rule that
you are
not allowed to pass transient
Am Wed, 06 Feb 2013 02:38:17 -0500
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
Regarding the questions about scope parameters and allowing in
On 2013-02-06 18:35, Jens Mueller wrote:
How about using YAML/JSON?
name: dwt
source: git://github.com/jacob-carlborg/dwt.git
The reason is that it will come a need for having conditions, variables
and similar in the YAML/JSON file. So instead of creating a new format,
or extending
On Thursday, 7 February 2013 at 06:23:10 UTC, Walter Bright wrote:
On 2/6/2013 10:13 PM, deadalnix wrote:
It is a given that @properties can't 100M emulate field, but
the goal should be
to close he gap as much as possible.
Ok, why should as much as possible be the goal? There are
other
On Thu, 07 Feb 2013 00:31:20 +0100, Timon Gehr wrote:
A.d:22:9: error: receiver for member function 'dup' is unqualified, but
'immutable' is required
f = g.dup;
^
Is this what you'd want?
Almost, it's definitely better, but what's wrong with:
immutable object
On 2013-02-06 22:09, Walter Bright wrote:
That's close enough to JSON to suggest: why not use JSON syntax?
See:
http://forum.dlang.org/thread/ugmacrokqghrrwpfo...@forum.dlang.org?page=4#post-kevo37:241gcn:241:40digitalmars.com
--
/Jacob Carlborg
On Thursday, 7 February 2013 at 05:54:29 UTC, deadalnix wrote:
On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:
In other words @safe should explicitly mean I hereby verify
that the code is safe not I will silently re-write your code
in unknown ways to make it safe.
@safe never
On 2013-02-06 16:41, Robert wrote:
:-) That is pretty much what I had in mind! Awesome! I would love to
help with this. I would start with some writing down of my ideas and
concepts I have in mind, if you are interested? If you are, where should
we discuss such things? On this mailing list?
On 2013-02-06 18:15, Dmitry Olshansky wrote:
I've been wondering what happened to it, looks fine I think.
I've been working on other projects for a while but now I've started to
work on it again.
--
/Jacob Carlborg
On Thursday, 7 February 2013 at 08:48:30 UTC, Rob T wrote:
On Thursday, 7 February 2013 at 05:54:29 UTC, deadalnix wrote:
On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:
In other words @safe should explicitly mean I hereby verify
that the code is safe not I will silently re-write
On 2/7/2013 12:22 AM, deadalnix wrote:
Ok, why should as much as possible be the goal? There are other
considerations - what merit should they have?
I don't think anyone have interest to get back on that. If you have another
answer to that question, please share.
The point is, there must
On Thu, 2013-02-07 at 09:45 +0100, Jacob Carlborg wrote:
Yes, I would be interested. I don't know what would be the best
communication channel.
Great! :-) I think for now, maybe this mailing list is not the worst
place. (At least I don't know a better one)
Best regards,
Robert
As Sönke Ludwig seems to work on something very similar, it might make
sense to join forces with him too. I will look into both implementations
next week, to see where we stand.
As I said, I will replace Ruby with D, that includes the DSL. It's the
only place where Ruby is used. The rest is
I think the opposite. When we think about more concepts in
Phobos, like gui, serialization, cryptography and so on, we
will be able to create the right amount of hierarchy with
distinguishable names. I'm in favor of a big batteries
included library.
Yeah, but I still think that breaking
On 2/6/2013 6:58 PM, deadalnix wrote:
Well Walter seems very worried about breaking code, but seems unable to adopt
any practice the reduce its effect, and in the facts, my cod break at any new
dmd release (and right now compile with none released one).
Here's the current list of regressions:
On 2013-02-06 19:56, Brad Anderson wrote:
I have a dream that someday phobos will just be a metapackage in a
package manager that installs a set of core modules.
What is needed to get Orbit off the ground (Kepler's law, I guess, would
be the joke answer)?
As with most things, it's time.
I
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright wrote:
The point is, there must always be a balance of competing
interests. That's certainly true here.
That is an assertion not an argument.
Does C# always allow taking the address of a getter's return
value? I don't know, but
On Thursday, 7 February 2013 at 06:36:22 UTC, H. S. Teoh wrote:
D ref types are currently highly crippled because of the
inability to
declare ref variables, which mandates ugly workarounds. It
should be a
first-class type qualifier IMO. (Yes I know it's currently a
*function*
qualifier, not a
On 2/7/2013 2:05 AM, deadalnix wrote:
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright wrote:
The point is, there must always be a balance of competing interests. That's
certainly true here.
That is an assertion not an argument.
Try designing anything by using one overriding
The solution to this problem has been posted already many times, simply
allow fields to be marked with @property too, having the compiler lower
it to a private field with trivial setter/getter method.
As I already mentioned, I don't really see the point of properties at
all, if they are not
On 2013-02-06 22:24, David Nadlinger wrote:
Somebody actually working on it.
No offense, Jacob, but to me it seems like you have quite a few
interesting projects (DVM, DStep, Orbit, …), and although you are
usually quick to advertise them here, it seems that none of them is
quite ready for
On Thursday, 7 February 2013 at 10:32:38 UTC, Walter Bright wrote:
On 2/7/2013 2:05 AM, deadalnix wrote:
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright
wrote:
The point is, there must always be a balance of competing
interests. That's
certainly true here.
That is an assertion
On Wed, 06 Feb 2013 17:36:24 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
A good part of that is the recent debate on what func should do (take
the address of the function vs. the address of its result). With the
unsafe meaning out of the way, only the safe one is
On 2/6/2013 8:06 PM, Chad Joan wrote:
Although I can sort of see the logic behind this convention, it is very hard to
think of a function that operates on ranges and automatically know which module
to look in.
Unfortunately, I don't think any reorg will help with that, as all functions
that
On 2013-02-06 18:22, Andrei Alexandrescu wrote:
I understand. The way I see this is as an motivation and opportunity to
add the necessary functionality to Phobos. I may be uninformed, but the
way I see it basic package management doesn't have to be very demanding
on library functionality.
No
Not so long ago, there was an amazing article about how user
defined types and formated writes behaved:
http://wiki.dlang.org/Defining_custom_print_format_specifiers
As cool as it is, I was writting a little user defined type, and
I wanted to the the contrary: un-format it to read it.
On Wednesday, 6 February 2013 at 22:25:03 UTC, Brad Anderson
wrote:
Reading more, it looks like Dub is his attempt to make VPM less
Vibe.d specific and more for general D use. It even generates
VisualD project files.
Cool stuff.
BA
Yeah, I'm leaning towards DUB for a few reasons.
The
On Thursday, 7 February 2013 at 13:27:14 UTC, monarch_dodra wrote:
...
For all the bashing C++'s and operators get, they at
least work both ways for UDTs.
...
I never understood why people like to bash about them.
I am yet to find a codebase in production where it is not obvious
from
On Thursday, 7 February 2013 at 05:30:27 UTC, Maxim Fomin wrote:
On Wednesday, 6 February 2013 at 22:54:40 UTC, Dan wrote:
This begs the question:
Which of these do you choose and for what reasons:
- this(this){}
This is natural way to define struct postblit. This fully
complies with
On 2/7/13 8:47 AM, Paulo Pinto wrote:
On Thursday, 7 February 2013 at 13:27:14 UTC, monarch_dodra wrote:
...
For all the bashing C++'s and operators get, they at least
work both ways for UDTs.
...
I never understood why people like to bash about them.
I am yet to find a codebase in
On Wed, 06 Feb 2013 21:53:25 -0500, deadalnix deadal...@gmail.com wrote:
On Wednesday, 6 February 2013 at 21:30:10 UTC, Timon Gehr wrote:
(fun, fun)
Agh, comma strikes again. It should be handled analogous to the ternary
expression. i.e. the expression above evaluates fun and then returns
On Wed, 06 Feb 2013 16:30:09 -0500, Timon Gehr timon.g...@gmx.ch wrote:
I do not have any hard data on this, but fun and (fun) meaning
different things is extremely confusing.
I can vouch that I find it confusing. At least on one other occasion,
Walter nixed a feature because of this.
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright wrote:
DIP25 aim to solve the ref issue. Which is clearly useful.
Conflating that goal
with making previous DIP on function call is only going to
export the mess in
another area of the language.
This is the very example of why
On 02/07/2013 02:56 PM, Steven Schveighoffer wrote:
On Wed, 06 Feb 2013 21:53:25 -0500, deadalnix deadal...@gmail.com wrote:
On Wednesday, 6 February 2013 at 21:30:10 UTC, Timon Gehr wrote:
(fun, fun)
Agh, comma strikes again. It should be handled analogous to the
ternary expression. i.e.
On Thu, 07 Feb 2013 01:06:34 -0500, Walter Bright
newshou...@digitalmars.com wrote:
The only time (now) that you can take the address of function return
value is if that is a return by ref. So, if taking the address of a ref
is disallowed, then the syntax is no longer ambiguous.
On 02/07/2013 03:58 AM, deadalnix wrote:
... my cod break at any new dmd release (and right now compile with none
released one).
+1. (I keep reporting regressions though, dustmite works quite well.)
On Wednesday, 6 February 2013 at 22:10:29 UTC, Robert wrote:
@properties are meant to emulate a field
You're in the wrong spot of the world. Everywhere else outside
the D community, the above assertion is held for true.
In the D community, it is not. Yes, there are places like that,
and
On Wed, 06 Feb 2013 23:26:03 -0500, Chad Joan chadj...@gmail.com wrote:
On 02/05/2013 09:45 PM, Steven Schveighoffer wrote:
...
The semantic rewrite stuff is something I don't feel strongly either
way. It would be nice, but at the same time, it doesn't feel necessary
to me. One can always
On 02/07/2013 02:49 PM, Dan wrote:
...
Why so much focus on new features like properties
I guess because it is not a new feature, but another part where some
things have not been hammered out sufficiently. (Also, it tends to
generate larger threads. :o) )
when the fundamentals of const
On 2013-02-07 09:19, Jacob Carlborg wrote:
That's way I originally chose Ruby, because it can look just like JSON:
foo = {
a: 3,
b: 4
}
This looks like JSON but doesn't look like Ruby. :)
On Thursday, 7 February 2013 at 15:03:20 UTC, Timon Gehr wrote:
const/immutable type checking currently is unsound during
object construction in general.
properties = candy
const/immutable soundness = meat potatoes
Evidence of tremedous energy and intellect here:
Am Thu, 07 Feb 2013 05:19:56 +0100
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Wednesday, 6 February 2013 at 21:07:24 UTC, Walter Bright
wrote:
On 2/6/2013 12:15 AM, Jonathan M Davis wrote:
I don't think that it's generally worth trying to rearrange
the modules that we
Am Thu, 07 Feb 2013 09:04:29 +0100
schrieb deadalnix deadal...@gmail.com:
On Thursday, 7 February 2013 at 07:41:57 UTC, Johannes Pfau wrote:
Am Wed, 06 Feb 2013 23:45:51 +0100
schrieb Robert jfanati...@gmx.at:
What happened to the scope storage class for parameters.
Wouldn't this
On Thu, 07 Feb 2013 15:02:41 -, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Wed, 06 Feb 2013 23:26:03 -0500, Chad Joan chadj...@gmail.com wrote:
On 02/05/2013 09:45 PM, Steven Schveighoffer wrote:
...
The semantic rewrite stuff is something I don't feel strongly either
way. It
Am Thu, 07 Feb 2013 04:02:29 +0100
schrieb deadalnix deadal...@gmail.com:
Well if JSON syntax is better than D's why D don' use JSON syntax
in the first place ?
JSON is a well known format. The benefit is, parsers exist for
every practical language and developers know by heart the
syntax and
On Thursday, 7 February 2013 at 14:44:36 UTC, eles wrote:
On Wednesday, 6 February 2013 at 22:10:29 UTC, Robert wrote:
@properties are meant to emulate a field
You're in the wrong spot of the world. Everywhere else outside
the D community, the above assertion is held for true.
In the D
On Thu, Feb 07, 2013 at 02:27:12PM +0100, monarch_dodra wrote:
Not so long ago, there was an amazing article about how user defined
types and formated writes behaved:
http://wiki.dlang.org/Defining_custom_print_format_specifiers
As cool as it is, I was writting a little user defined type,
Hello,
Having a ddoc mode for emacs would make documentation writing a lot more
enjoyable. Is there anyone who's versed in defining emacs modes?
Ddoc files have a simple structure: $(name introduces a level of
indentation (e.g. 2 spaces) and gets highlighted, ) deindents, and at
the end
On 2/7/13 9:44 AM, eles wrote:
On Wednesday, 6 February 2013 at 22:10:29 UTC, Robert wrote:
@properties are meant to emulate a field
You're in the wrong spot of the world. Everywhere else outside the D
community, the above assertion is held for true.
In the D community, it is not. Yes,
On 2/7/13 10:55 AM, Dicebot wrote:
On Thursday, 7 February 2013 at 14:44:36 UTC, eles wrote:
On Wednesday, 6 February 2013 at 22:10:29 UTC, Robert wrote:
@properties are meant to emulate a field
You're in the wrong spot of the world. Everywhere else outside the D
community, the above
Am Wed, 06 Feb 2013 23:06:06 -0500
schrieb Chad Joan chadj...@gmail.com:
I just want to say PLEASE YES. Phobos' module hierarchy is currently
confusing at best, especially with various important elements being
scattered across std.range, std.algorithm, std.array, and maybe another
I'm
Heh, after that many topics and discussion I have started to
think it would have been better if initial proposal to remove
them altogether succeeded.
Same feeling here. But I'll try to be constructive and I hope I find the
time to write yet another DIP about properties next week.
UFCS and
On 2013-02-06 23:14, Maxim Fomin wrote:
On Wednesday, 6 February 2013 at 21:47:35 UTC, Dan wrote:
On Wednesday, 6 February 2013 at 20:30:40 UTC, Maxim Fomin wrote:
The fact that bar() does not work and (bar)() works is terrific.
Sorry - but I don't understand what is terrific? Is this
On Thursday, 7 February 2013 at 09:21:38 UTC, deadalnix wrote:
On Thursday, 7 February 2013 at 08:48:30 UTC, Rob T wrote:
On Thursday, 7 February 2013 at 05:54:29 UTC, deadalnix wrote:
On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:
In other words @safe should explicitly mean I
Properties provide a means of access control to fields. (Range checks,
only readable, only writable, triggering a signal on change, ...)
So as posted a few times, taking the address of the ref return value of
a property is of no value at all. If you want someone to be able to take
the address of
Recently quickfur and Andrei have added C++-style functions
(nextPermutation and nextEvenPermutation) to std.algorithm to
perform permutations, this is a Phobos improvement and I've
already used them few times:
On 2013-02-07 19:05, Robert wrote:
taking the address of the ref return value of a property is of no
value at all. If you want someone to be able to take the address
of a field, you should make it simply public (without @property),
because the @property accessor methods won't gain you anything
On Thu, Feb 07, 2013 at 07:22:10PM +0100, bearophile wrote:
Recently quickfur
That's my github handle.
and Andrei have added C++-style functions (nextPermutation and
nextEvenPermutation) to std.algorithm to perform permutations, this is
a Phobos improvement and I've already used them few
On Thursday, 7 February 2013 at 16:35:17 UTC, Andrei Alexandrescu
wrote:
I felt we were getting somewhere.
Andrei
Both yes and no at the same time.
Last proposals did a great job addressing different issues
regarding property syntax and I somewhat like them in that sense.
But they miss an
On Wednesday, 6 February 2013 at 07:56:26 UTC, Don wrote:
In the Implementing Half Floats in D thread, we seemed to
have reached a consensus on two important points:
(a) Phobos should have a broad scope (rather than being small
like the C standard library).
(b) The current flat structure of
On Thu, Feb 07, 2013 at 07:55:22PM +0100, Dicebot wrote:
On Thursday, 7 February 2013 at 16:35:17 UTC, Andrei Alexandrescu
wrote:
I felt we were getting somewhere.
Andrei
Both yes and no at the same time.
Last proposals did a great job addressing different issues regarding
property
On Thu, 07 Feb 2013 13:05:50 -0500, Robert jfanati...@gmx.at wrote:
Properties provide a means of access control to fields. (Range checks,
only readable, only writable, triggering a signal on change, ...)
So as posted a few times, taking the address of the ref return value of
a property is of
Good point, but I think that this is pretty much a corner case where it
occasionally might be useful, but it does not rectify the consequences:
The moment you are allowed to take the address, you are stuck with the
ref returning accessor and can not change it later to a get/set pair.
An easy
Someone is already working on std.combinatorics
That's me. I'm very bust atm with work, so I haven't been able to
do much with it lately, but it is progressing.
1) To avoid excessive allocations, it would have to be a
transient
range. Which means it may have unexpected results if you use
H. S. Teoh:
1) To avoid excessive allocations, it would have to be a
transient range.
See the doCopy boolean template argument in my code. Note that
it's true on default. (D Zen: do the safe thing on default, and
the fast thing on request).
2) If the starting range is not sorted, then
On 2/7/2013 6:15 AM, Zach the Mystic wrote:
Can you tell me if you consider my proposal with regard to making ref safe and
complete simple and intuitive both for compiler and user, and if not, why? (I
don't have an opinion about '' yet.)
On 2/7/2013 3:16 AM, deadalnix wrote:
The 'funny' things is that C#'s would cause syntax problem issue with address
of,
where D does.
I don't understand this sentence.
In C#, foo.bar won't execute bar's method of foo. It will get what is called in
D a delegate. foo.bar() execute that
On Thu, Feb 07, 2013 at 08:40:25PM +0100, Peter Alexander wrote:
[...]
1) To avoid excessive allocations, it would have to be a transient
range. Which means it may have unexpected results if you use it with
an algorithm that doesn't handle transient ranges correctly.
This has been discussed
On Thu, Feb 07, 2013 at 08:47:39PM +0100, bearophile wrote:
H. S. Teoh:
1) To avoid excessive allocations, it would have to be a transient
range.
See the doCopy boolean template argument in my code. Note that it's
true on default. (D Zen: do the safe thing on default, and the fast
thing
On Thursday, February 07, 2013 13:17:20 Jacob Carlborg wrote:
On 2013-02-06 18:22, Andrei Alexandrescu wrote:
I understand. The way I see this is as an motivation and opportunity to
add the necessary functionality to Phobos. I may be uninformed, but the
way I see it basic package management
On 2/7/13 2:13 PM, Steven Schveighoffer wrote:
On Thu, 07 Feb 2013 13:05:50 -0500, Robert jfanati...@gmx.at wrote:
Properties provide a means of access control to fields. (Range checks,
only readable, only writable, triggering a signal on change, ...)
So as posted a few times, taking the
On Thursday, 7 February 2013 at 16:33:46 UTC, Andrei Alexandrescu
wrote:
On 2/7/13 9:44 AM, eles wrote:
On Wednesday, 6 February 2013 at 22:10:29 UTC, Robert wrote:
I think the sarcasm is uncalled for. We're doing our best here
and our intent is indeed to have properties emulate fields.
At
H. S. Teoh:
any implementation based on factorial would have to
address the issue of how to handle the exponential growth. I
think it'sunacceptable for the standard library to support
permutations only up to ranges of 20 elements or less,
because 21! 2^64.
What are the use cases of
On Thursday, February 07, 2013 10:02:41 Steven Schveighoffer wrote:
On Wed, 06 Feb 2013 23:26:03 -0500, Chad Joan chadj...@gmail.com wrote:
On 02/05/2013 09:45 PM, Steven Schveighoffer wrote:
...
The semantic rewrite stuff is something I don't feel strongly either
way. It would be
On Thu, Feb 07, 2013 at 09:24:24PM +0100, bearophile wrote:
H. S. Teoh:
any implementation based on factorial would have to address the issue
of how to handle the exponential growth. I think it'sunacceptable for
the standard library to support permutations only up to ranges of 20
elements
H. S. Teoh:
Combinatorial puzzles come to mind (Rubik's cube solvers and
its ilk,
for example). Maybe other combinatorial problems that require
some kind
of exhaustive state space search. Those things easily go past
20! once
you get beyond the most trivial cases.
I know many
It depends on how we are going to define properties and with all the
arguments in the discussions it seems to me that the only sane way to
design properties is as simple front ends for private fields (which is
my understanding of properties anyway).
But with optional parantheses the @property
Just to be clear here, with DIP23 in place, the syntax at the caller
side for:
@property ref T front(T[] arr) { return arr[0];}
would not change if you remove the @property. So little code breakage
here and the code that breaks is easily fixed by removing @property.
08-Feb-2013 00:04, H. S. Teoh пишет:
On Thu, Feb 07, 2013 at 08:40:25PM +0100, Peter Alexander wrote:
[...]
1) To avoid excessive allocations, it would have to be a transient
range. Which means it may have unexpected results if you use it with
an algorithm that doesn't handle transient ranges
On Thursday, 7 February 2013 at 20:26:10 UTC, Jonathan M Davis
wrote:
It works as long as you can limit the variable in some way. But
I believe that
the main purpose in using public variables rather than actual
property
functions when all they would do is get or set the variable is
to avoid
struct S
{
@property int i;
}
You missed the point. When this gets lowered to accessor functions and a
private variable, you ensure that you can later on add your magic soup,
without breaking code that relied on i being a real field. (E.g. taking
the address, using +=, -=, ...)
On Thu, 07 Feb 2013 15:57:56 -0500, Robert jfanati...@gmx.at wrote:
Just to be clear here, with DIP23 in place, the syntax at the caller
side for:
@property ref T front(T[] arr) { return arr[0];}
would not change if you remove the @property. So little code breakage
here and the code that
On Wednesday, 6 February 2013 at 18:47:35 UTC, Brad Anderson
wrote:
On Wednesday, 6 February 2013 at 11:38:31 UTC, Dicebot wrote:
AFAIR there was proposal of a future meta package for
introducing new modules with time to adapt, similar to how it
is done in few other languages.
I really like
On Thu, 07 Feb 2013 15:14:22 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 2/7/13 2:13 PM, Steven Schveighoffer wrote:
On Thu, 07 Feb 2013 13:05:50 -0500, Robert jfanati...@gmx.at wrote:
Properties provide a means of access control to fields. (Range checks,
only
On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis jmdavisp...@gmx.com
wrote:
struct S
{
@property int i;
}
struct S
{
mixin(boilerplateProperty(i));
}
I don't see this as a difficult problem to solve.
-Steve
On Thursday, 7 February 2013 at 21:12:35 UTC, Steven
Schveighoffer wrote:
struct S
{
mixin(boilerplateProperty(i));
}
I don't see this as a difficult problem to solve.
-Steve
+1
In C#, they have introduced automatic properties for that purpose
of initial encapsulation:
public int i { get; set; } //get and set can be modified with
private etc
Then the getter and setter methods are automatically implemented.
I'm not closely following the discussions involved in the
On Thursday, 7 February 2013 at 21:05:49 UTC, Robert wrote:
You missed the point. When this gets lowered to accessor
functions and a
private variable, you ensure that you can later on add your
magic soup,
without breaking code that relied on i being a real field.
(E.g. taking
the address,
On 2013-02-06 23:00, Andrei Alexandrescu wrote:
I'll start with some top posting and summarize. I use what works. If
that means using some third party library I have no problem with that.
Why should I reimplement something and hope for inclusion into Phobos
when there already exist a
On Thu, 2013-02-07 at 16:08 -0500, Steven Schveighoffer wrote:
int delegate()[] arr;
arr.front();
That's part of the mess we are trying to clean up here? As of DIP 23,
you would have to do arr.front()() in order to actually call the
delegate.
The current behaviour is also that you have to do
1 - 100 of 242 matches
Mail list logo
