Re: exceptions vs error codes
On Wednesday, 13 July 2016 at 09:04:20 UTC, ketmar wrote: On Wednesday, 13 July 2016 at 07:14:04 UTC, Max Samukha wrote: Undefined does not imply corrupt. undefined means "undefined". there is nothing more to save, nothing more to do, as you can't rely on a single bit. this is... definition of undefined. relying on defined state with undefined behavior is not only dangerous, it is plainly invalid. Not true. Undefined implies there *may* be something to save. That is why programs like Steinberg Cubase do not simply bail out on failure, but give users a chance to save a copy of their work. In my experience with Cubase, state needed for recovery survived the failure more often than not.
Re: exceptions vs error codes
On Sunday, 10 July 2016 at 16:57:49 UTC, ketmar wrote: On Sunday, 10 July 2016 at 16:47:31 UTC, Chris Wright wrote: You do need a try/catch in every annotated function to catch runtime exceptions like OutOfMemoryError. as a side note: it is even not guaranteed that one *can* catch Error. and it is plainly wrong to try to continue execution after that, as program is in undefined state. Undefined does not imply corrupt. There are many examples of programs that give you the last chance to save the state after a failure.
Re: Rant after trying Rust a bit
On Thursday, 6 August 2015 at 06:54:45 UTC, Walter Bright wrote:
On 8/3/2015 2:19 AM, Max Samukha wrote:
The point is that '+' for string concatenation is no more of
an 'idiot thing'
than '~'.
Sure it is. What if you've got:
T add(T)(T a, T b) { return a + b; }
and some idiot overloaded + for T to be something other than
addition?
That is a general problem with structural typing. Why not assume
that if a type defines 'length', it must be a range? Then call an
idiot everyone who defines it otherwise. I admit that special
treatment of '+' is justified by its long history, but 'idiot
thing' is obviously out of place.
BTW, it happens that '+' does not always have to be commutative:
https://en.wikipedia.org/wiki/Near-ring
https://en.wikipedia.org/wiki/Ordinal_arithmetic#Addition
Re: Vision for the D language - stabilizing complexity?
On Saturday, 9 July 2016 at 14:58:55 UTC, Andrew Godfrey wrote: On Saturday, 9 July 2016 at 06:31:01 UTC, Max Samukha wrote: On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey wrote: This is a tangent from the subject of this thread, but: No, that just says how it is implemented, not what it means / intends. See "the 7 stages of naming", here: http://arlobelshee.com/good-naming-is-a-process-not-a-single-step/ (That resource is talking about identifier naming, not keywords. But it applies anyway.) You have a point, but the name is still not 'just bonkers', all things considered. Metonymy is justified in many cases, and I think this is one of them. What better name would you propose?
Re: Vision for the D language - stabilizing complexity?
On Saturday, 9 July 2016 at 04:32:25 UTC, Andrew Godfrey wrote: Aha! But I don't! It feels intuitive, possibly the best use of "static". But that is immaterial, what matters is the sum of all meanings of "static" in this language. The "single instance per class" meaning of "static" is just bonkers. I've had that meaning burned into my brain for a couple of decades, from C++. But I don't have to like it! I could stomach it, though, if that was the only use of the keyword. (Or if the other meanings couldn't be used in the same contexts). The name is fine. It comes from 'statically bound/dispatched', that is 'resolved at compile time'.
Re: Monads in D
On Sunday, 12 June 2016 at 16:46:13 UTC, Ola Fosheim Grøstad wrote: Input world, output modified world... Geez, why doesn't tutorials on Monads say that before they try to explain it with code? Because IO is just one of many applications of the monad concept?
Re: Monads in D
On Saturday, 11 June 2016 at 18:27:19 UTC, deadalnix wrote: I could go on, but this guy already did it way better that I can: https://www.infoq.com/presentations/functional-pros-cons The part about monad starts 25mins in. The guy is good.
Re: Passing private functions to template algorithms
On Tuesday, 7 June 2016 at 18:59:03 UTC, Timon Gehr wrote:
I think it is obvious that this should work. Visibility checks
need to happen during identifier lookup. This lookup is
happening in the module where isFileNothrow is visible.
There is also this inconsistency:
module a;
private int _x;
alias x = _x;
private void _foo() {
}
alias foo = _foo;
module main;
import a;
void main(string[] args)
{
x = 1; // ok
foo(); // a._foo is not accessible
}
What's the reason for this? Should both aliases be private?
Public?
Re: Passing private functions to template algorithms
On Wednesday, 8 June 2016 at 00:48:00 UTC, Stefan Koch wrote: On Tuesday, 7 June 2016 at 18:59:03 UTC, Timon Gehr wrote: I think it is obvious that this should work. Visibility checks need to happen during identifier lookup. This lookup is happening in the module where isFileNothrow is visible. I agree with you. However something in the back of my mind tells me that we'll be hitting nasty corner cases if we change the behavior. Something in the back of mine tells that no corner cases can be worse than the present situation. It is like disallowing private variables to be passed to imported functions.
Re: Code runtime
On Sunday, 5 June 2016 at 21:52:20 UTC, Ausprobierer wrote: Then I've replicated this code in MSVS2015 C++: Note that 'long' in D is 64 bits, whereas in MSVC it is 32 bits.
Re: The Case Against Autodecode
On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu wrote: If user code needs to go upper at the grapheme level, they can If anything this thread strengthens my opinion that autodecoding is a sweet spot. -- Andrei Unicode FAQ disagrees (http://unicode.org/faq/utf_bom.html): "Q: How about using UTF-32 interfaces in my APIs? A: Except in some environments that store text as UTF-32 in memory, most Unicode APIs are using UTF-16. With UTF-16 APIs the low level indexing is at the storage or code unit level, with higher-level mechanisms for graphemes or words specifying their boundaries in terms of the code units. This provides efficiency at the low levels, and the required functionality at the high levels."
Re: Always false float comparisons
On Friday, 20 May 2016 at 06:12:44 UTC, Walter Bright wrote: If you say so. I would like to see an example that demonstrates that the first roundToDouble is required. That's beside the point. If there are spots in the program that require rounding, what is wrong with having to specify it? Because the programmer has already specified it with a type that requires rounding! Why compromise speed & accuracy in the rest of the code that does not require it? (And yes, rounding in certain spots can and does compromise both speed and accuracy.) Accuracy and speed won't be compromised if the programmer chooses an appropriate type - 'real' for the highest precision supported by the implementation. BTW, you need to remove 'hardware' from the definition of 'real' in the spec.
Re: Always false float comparisons
On Thursday, 19 May 2016 at 07:09:30 UTC, Walter Bright wrote:
On 5/18/2016 10:10 AM, Timon Gehr wrote:
double kahan(double[] arr){
double sum = 0.0;
double c = 0.0;
foreach(x;arr){
double y=x-c;
double y = roundToDouble(x - c);
double t=sum+y;
double t = roundToDouble(sum + y);
c = (t-sum)-y;
sum=t;
}
return sum;
}
Those are the only two points in the program that depend on
rounding. If you're implementing Kahan, you'd know that, so
there shouldn't be anything difficult about it.
There's no reason to make the rest of the program suffer
inaccuracies.
People are trying to get across that, if they wanted to maximize
accuracy, they would request the most precise type explicitly. D
has 'real' for that. This thread has shown unequivocally that the
semantics you are insisting on is bound to cause endless
confusion and complaints.
Re: Always false float comparisons
On Monday, 16 May 2016 at 19:01:19 UTC, Timon Gehr wrote: You are not even guaranteed to get the same result on two different x86 implementations. Without reading the x86 specification, I think it is safe to claim that you actually are guaranteed to get the same result. Correct. Sorry for the noise. AMD64: "The processor produces a floating-point result defined by the IEEE standard to be infinitely precise. This result may not be representable exactly in the destination format, because only a subset of the continuum of real numbers finds exact representation in any particular floating-point format." This just says that results of computations will need to be rounded to fit into constant-size storage. Right.
Re: Always false float comparisons
On Monday, 16 May 2016 at 14:21:34 UTC, Ola Fosheim Grøstad wrote: C++17 is getting hex literals for floating point for a reason: accurate bit level representation. D has had hex FP literals for ages.
Re: Always false float comparisons
On Monday, 16 May 2016 at 10:25:33 UTC, Andrei Alexandrescu wrote: On 5/16/16 12:37 AM, Walter Bright wrote: Me, I think of that as "Who cares that you paid $$$ for an 80 bit CPU, we're going to give you only 64 bits." I'm not sure about this. My understanding is that all SSE has hardware for 32 and 64 bit floats, and the the 80-bit hardware is pretty much cut-and-pasted from the x87 days without anyone really looking in improving it. And that's been the case for more than a decade. Is that correct? I'm looking for example at http://nicolas.limare.net/pro/notes/2014/12/12_arit_speed/ and see that on all Intel and compatible hardware, the speed of 80-bit floating point operations ranges between much slower and disastrously slower. I think it's time to revisit our attitudes to floating point, which was formed last century in the heydays of x87. My perception is the world has moved to SSE and 32- and 64-bit float; the "real" type is a distraction for D; the whole let's do things in 128-bit during compilation is a time waster; and many of the original things we want to do with floating point are different without a distinction, and a further waste of our resources. It is a bit ironic that we worry about autodecoding (I'll destroy that later) whilst a landslide loss of speed and predictability in floating point math doesn't raise an eyebrow. Andrei The AMD64 programmer's manual discourages the use of x87: "For media and scientific programs that demand floating-point operations, it is often easier and more powerful to use SSE instructions. Such programs perform better than x87 floating-point programs, because the YMM/XMM register file is flat rather than stack-oriented, there are twice as many registers (in 64-bit mode), and SSE instructions can operate on four or eight times the number of floating-point operands as can x87 instructions. This ability to operate in parallel on multiple pairs of floating-point elements often makes it possible to remove local temporary variables that would otherwise be needed in x87 floating-point code."
Re: Always false float comparisons
On Monday, 16 May 2016 at 04:02:54 UTC, Manu wrote: extended x = 1.3; x + y; If that code were to CTFE, I expect the CTFE to use extended precision. My point is, CTFE should surely follow the types and language semantics as if it were runtime generated code... It's not reasonable that CTFE has higher precision applied than the same code at runtime. CTFE must give the exact same result as runtime execution of the function. You are not even guaranteed to get the same result on two different x86 implementations. AMD64: "The processor produces a floating-point result defined by the IEEE standard to be infinitely precise. This result may not be representable exactly in the destination format, because only a subset of the continuum of real numbers finds exact representation in any particular floating-point format."
Re: Always false float comparisons
On Sunday, 15 May 2016 at 12:11:58 UTC, deadalnix wrote: Yes. What is the proportion of CTFE floating point operation right know in the total compile time ? I'd be highly supersized if it was anything close to 1% . That was said about CTFE in general before people started to use it and discovered it is unusable because of performance issues (vibe.d is a prominent example).
Re: Github names & avatars
On Friday, 13 May 2016 at 18:56:15 UTC, Walter Bright wrote: When I was old, I realized nobody thought about me. I did. Then I saw this http://joshworth.com/dev/pixelspace/pixelspace_solarsystem.html and stopped. Seriously, captcha that requires programmers to do basic arithmetics is a horrible idea. It's like having a gynecologist watch porn. To make it worse, DPaste doesn't compile the code as is.
Re: Researcher question – what's the point of semicolons and curly braces?
On Wednesday, 4 May 2016 at 04:39:46 UTC, Walter Bright wrote: One of the things that comes with Haskell has nothing to do with functional programming. It's the minimalist syntax. However, I find that they've gone too far with this, and it's difficult for me to read. Haskell people, however, consider this 'clean'. It is actually no harder to read after some practice than a language with C-like syntax. In general, the more languages you practice, the less important (and more annoying) syntax redundancies become.
Re: Some questions on latest work
On Tuesday, 26 April 2016 at 18:16:42 UTC, Joakim wrote: He gave very specific criticism, along with a code sample, then made a prediction, followed by suggesting another competing language that might do better. None of that is the usual content-free fanboy "bashing." There is nothing wrong with occasional criticism of the competition, as long as we don't overdo it, either in frequency or by exaggerating. No, judging a language by the appearance of its syntax *is* fanboy bashing. BTW, some interesting points about Swift made by a Rust designer http://graydon2.dreamwidth.org/5785.html.
Re: extern(C++, ns)
On Monday, 18 January 2016 at 10:24:28 UTC, Walter Bright wrote: A known problem is that D doesn't put destructors in the vtbl[] for C++ classes, although it should. Also, virtual destructors on Linux 64 consume 2 slots in the vtbl[], which surprised me. One is for the destructor, the other - for the destructor and delete.
Re: [OT] LLVM Community Code of Conduct
On Friday, 16 October 2015 at 08:29:18 UTC, Kagamin wrote: On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote: I agree with logicchains. The impression people have is exactly this. Go = neat and tidy, D = mess. Do people have the same impression from generic code in Go? Crutches help them move along: http://blog.golang.org/generate
Re: Pathing in the D ecosystem is generally broken (at least on windows)
On Monday, 28 September 2015 at 21:41:27 UTC, rumbu wrote: Dear Walter, Pressing Ctrl-C in any *standard* dialog will copy the text to clipboard since Windows 2000, even captions and buttons. No, standard label controls still don't let you select and copy the text. And that sucks.
Re: Rant after trying Rust a bit
On Wednesday, 5 August 2015 at 15:58:28 UTC, Timon Gehr wrote: The point is that '+' for string concatenation is no more of an 'idiot thing' than '~'. My point is that it is. String concatenation is not commutative. Ok, good point. Except that '+' in a programming language is not the mathematical '+'. Why define '+' as strictly commutative operation and not more generally as an abstract binary operation, considering the middle dot is unavailable? Or, if we want to stick to the math notation, then '*' would be more appropriate than the idiot thing '~'.
Re: Rant after trying Rust a bit
On Monday, 3 August 2015 at 06:52:41 UTC, Timon Gehr wrote: On 08/02/2015 09:02 PM, Max Samukha wrote: On Sunday, 26 July 2015 at 23:29:18 UTC, Walter Bright wrote: For example, the '+' operator. Rust traits sez "gee, there's a + operator, it's good to go. Ship it!" Meanwhile, you thought the function was summing some data, when it actually is creating a giant string, or whatever idiot thing someone decided to use '+' for. Number addition and string concatenation are monoid operations. In this light, '+' for both makes perfect sense. '+' is usually used to denote the operation of an abelian group. The point is that '+' for string concatenation is no more of an 'idiot thing' than '~'.
Re: Rant after trying Rust a bit
On Sunday, 26 July 2015 at 23:29:18 UTC, Walter Bright wrote: For example, the '+' operator. Rust traits sez "gee, there's a + operator, it's good to go. Ship it!" Meanwhile, you thought the function was summing some data, when it actually is creating a giant string, or whatever idiot thing someone decided to use '+' for. Number addition and string concatenation are monoid operations. In this light, '+' for both makes perfect sense.
Re: D could catch this wave: web assembly
On Thursday, 18 June 2015 at 11:00:37 UTC, ketmar wrote: piles of shit on top of piles of shit A good definition of evolution.
Re: The amazing template which does nothing
On Tuesday, 28 April 2015 at 02:36:38 UTC, Vladimir Panteleev
wrote:
http://blog.thecybershadow.net/2015/04/28/the-amazing-template-which-does-nothing/
A truly polymorphic identity function in D would be more involved:
template id(a...) if (a.length == 1)
{
static if (__traits(compiles, { alias id = a[0]; } ))
alias id = a[0];
else
enum id = a[0];
}
static assert(is(id!int == int));
static assert(id!1 == 1);
Also, an 'isEqual' template would be needed to unify 'isSame',
'is' and '=='.
Re: DIP69 - Implement scope for escape proof references
On Saturday, 13 December 2014 at 02:55:50 UTC, Manu via Digitalmars-d wrote: Templates and functions are different things. I think it's a massive mistake to have created a way to write a template that looks nothing like a template. That is a misconception spread by C++. Templates are pure functions applied at compile time. Function templates are functions partially applied at compile time.
Re: Why is `scope` planned for deprecation?
On Sunday, 16 November 2014 at 03:27:54 UTC, Walter Bright wrote: On 11/14/2014 4:32 PM, deadalnix wrote: To quote the guy from the PL for video games video serie, a 85% solution often is preferable. Spoken like a true engineer! 85% often means being at the bottom of the uncanny valey. 65% or 95% are more preferable.
Re: John Carmack on Functional Programming in C++
On Sunday, 16 November 2014 at 18:06:32 UTC, Walter Bright wrote: http://gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php Anything John writes is well worth reading, this article included. He includes as shout out to D! Also https://www.youtube.com/watch?v=1PhArSujR_A, where he's talking about functional programming, Haskell and stuff.
Re: Microsoft now giving away VS 2013
On Friday, 14 November 2014 at 20:29:26 UTC, Dmitry Olshansky wrote: Classics! :) I love these kinds of statements with "heavy lifting" and "great scalability" and "huge amounts of data". And things like e.g. Python web frameworks claiming to be "super fast" at request routing because they compile regular expressions at start-up. How smart... OMG. Simulating brains is just around the corner!
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 01:26:37 UTC, Walter Bright wrote: If you sit around waiting for arbitrary perfection, you'll never get any work done. I don't care that my truck has dings in it, either, it's a truck and it's useful for what I need it for :-) Even though a Tesla is of no more use than your old ugly truck, I still favor the former. :P
Re: TypeInfo in the library
On Friday, 14 February 2014 at 20:05:53 UTC, Rainer Schuetze
wrote:
The only drawback I see is that it makes compilation a bit
slower and pollutes object files with code just executed during
CTFE.
Currently, the bloat can be reduced like this:
void foo()
{
if (__ctfe)
{
// function body
}
else
asm { naked; }
}
But that's an awful dangerous hack. A better solution is needed.
Re: Which tools do you miss in D?
On Monday, 27 January 2014 at 08:24:07 UTC, Manu wrote: I'm quite serious, this is a true realisation of an unconscious behaviour. D ruined C/C++ for me, but my expectations of C/C++'s tooling still remains a barrier to my enjoyment of writing D code all time time... I'm fucked! Similar experience here. D has ruined my enjoyment of writing code in any language including D :).
Re: Inherent code performance advantages of D over C?
On Thursday, 12 December 2013 at 20:46:26 UTC, Walter Bright wrote: On 12/12/2013 12:33 PM, Max Samukha wrote: Don't you find it somewhat alarming that both alternative compilers follow neither the standard inline asm nor ABI? I find it unfortunate. But it also can be difficult and time consuming to reimplement an assembler for those back ends, so I can understand why it isn't a priority. You know that it is not likely to ever be a priority. That's what will happen: lots of code will be written, using the peculiarities of each implementation. And then nobody will want to change the status quo becase "it will break lots of code".
Re: Inherent code performance advantages of D over C?
On Thursday, 12 December 2013 at 20:24:19 UTC, Walter Bright wrote: On 12/12/2013 12:16 PM, Max Samukha wrote: But the question is what to do about other targets? What about ARM, MIL, LLVM IR or whatever low-level target a D compiler may compile too? Will those be standardized as part of the language? I certainly think they ought to be. Don't you find it somewhat alarming that both alternative compilers follow neither the standard inline asm nor ABI? Maybe it would be wiser to call those standard extentions or whatever than claiming they are part of the language?
Re: Inherent code performance advantages of D over C?
On Thursday, 12 December 2013 at 20:06:37 UTC, Walter Bright wrote: On 12/12/2013 11:57 AM, Max Samukha wrote: On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote: 11. inline assembler being a part of the language rather than an extension that is in a markedly different format for every compiler Ahem. If we admit that x86 is not the only ISA in exsistence, then what is (under)specified here http://dlang.org/iasm.html is a platform-specific extension. I know of at least 3 different C x86 inline assembler syntaxes. This is not convenient, to say the least. I know that too. I appreciate that you attempted to standardize the asm for x86. But the question is what to do about other targets? What about ARM, MIL, LLVM IR or whatever low-level target a D compiler may compile too? Will those be standardized as part of the language?
Re: Inherent code performance advantages of D over C?
On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright wrote: 11. inline assembler being a part of the language rather than an extension that is in a markedly different format for every compiler Ahem. If we admit that x86 is not the only ISA in exsistence, then what is (under)specified here http://dlang.org/iasm.html is a platform-specific extension.
Re: Probable C# 6.0 features
On Wednesday, 11 December 2013 at 05:14:56 UTC, Walter Bright wrote: On 12/10/2013 3:53 PM, Ary Borenszweig wrote: BTW, the other day I friend tried to explain me monads and he realized couldn't understand them himself The best way to learn something is to try to explain it to someone else. Some things are very hard to explain because explaining them requires a lot of context unknown to the recipient, and there is no appropriate analogy to pass that context "by reference". So it's often wiser to give up and let the other person acquire the context on his own. Explaining monads to other people is a waste of time :). There is an interesting write-up by Dijkstra, which touches this subject as well http://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF.
Re: demangle doesn't work with __ModuleInfoZ __initZ __arrayZ
On Monday, 27 May 2013 at 15:22:21 UTC, Peter Alexander wrote: On Monday, 27 May 2013 at 04:12:23 UTC, deadalnix wrote: On Sunday, 26 May 2013 at 23:38:33 UTC, Timothee Cour wrote: Is there any plan to support demangling of those: __ModuleInfoZ __initZ __arrayZ ? I have a lot of stuff that do not demangle properly with any tools. I give you one, just for fun :D D1d6parser9statement308__T14parseStatementTS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ14parseStatementFKS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZC1d3ast9statement9Statement1004__T28parseDeclarationOrExpressionS6781d6parser9statement308__T14parseStatementTS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7! dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ14parseStatementFKS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZC1d3ast9statement9Statement13__dgliteral23TS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ28parseDeclarationOrExpressionMFKS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAy! aZ3lexMFAyaZ5LexerZC1d3ast9statement9Statement2029__T14parseAmbiguousS17161d6parser9statement308__T14parseStatementTS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ14parseStatementFKS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZC1d3ast9statement9Statement1004__T28parseDeclarationOrExpressionS6781d6parser9statement308__T14parseStatementTS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7! dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ14parseStatementFKS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZC1d3ast9statement9Statement13__dgliteral23TS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11__lambda125TAyaZ3lexMFAyaZ5LexerZ28parseDeclarationOrExpressionM12__dgliteral9TS1d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZ159__T3lexS1431d8semantic8semantic12SemanticPass35__T5parseTC1d8location10FileSourceZ5parseMFC1d8location10FileSourceAAyaZC1d3ast7dmodule6Module11_! _lambda125TAyaZ3 Am I the only person that worries greatly about the length of symbols in D? No. That's a significant problem.
Re: Inherent code performance advantages of D over C?
On Saturday, 7 December 2013 at 00:40:52 UTC, Manu wrote: Assuming a comparison to C++, you know perfectly well that D has a severe disadvantage. Unless people micro-manage final (I've never seen anyone do this to date), I do. Whether a function should be virtual is a design decision that needs to be made form the outset. Having all class functions freely overridable is not a good idea. then classes will have significantly inferior performance to C++. C++ coders don't write virtual on everything. Especially not trivial accessors which must be inlined.
Re: D Programmer Jobs at Sociomantic Labs
On Friday, 6 December 2013 at 21:06:43 UTC, Andrei Alexandrescu wrote: Degrees help for things like immigration, where some bureaucratic rules must be obeyed. There may be country laws that prohibit certain positions without the degree. Otherwise they should be mostly advisory for a good company. One of the best engineers at Facebook doesn't have a degree and was homeless at hire time. He failed two of three interviews, too. True story. I somewhat regret I do not have a solid formal background in a field involving higher math. Educating oneself on the hoof is a rather painful process, though it has some advantages.
Re: D vs Go in real life, part 2. Also, Erlang.
On Thursday, 5 December 2013 at 14:55:53 UTC, Jeff R. Allen wrote: I am the buddy who's always going on and on about Go. Here's the blog posting I made explaining why/how I made the MQTT server in Go and what I learned: http://blog.nella.org/mqtt-code-golf/ I was a bit surprised and interested to see that MQTT with small transactions is not easy to optimize because kernel/user context switching dominates the work that's done under control of the programmer and which can be optimized via data structures and/or reducing GC overhead. Something that both Atila and I verified in this exercise is that writing a fast network server that scales is so much easier with a very good networking library that takes advantage of lightweight threads, and with a runtime that provides GC. This frees up the programmer to focus on the protocol logic, and leave concurrency and bookkeeping in the capable hands of the machine. And, as has been mentioned on other Go versus D threads, a lot of this is a matter of taste and team dynamics. I've worked on many teams in my career where there was not a critical mass of people who could reason correctly about C++ memory management, and who could use generic programming techniques reliably. And, in line with discoveries from psychological research, it's common that people who are not competent at something do not recognize that fact. Perhaps I'm above average in this regard: I KNOW I'm not smart enough to write correct code using templating techniques. :) -jeff Templates are easy. They are pure functions. You just need to overcome idiosyncrasies introduced by people who thought they were something else. ;)
Re: dmd git head completely broken on ubuntu (but not osx)
On Thursday, 5 December 2013 at 19:18:01 UTC, Timothee Cour wrote: https://d.puremagic.com/issues/show_bug.cgi?id=11684 is a pretty serious regression: when building dmd/druntime/phobos from source, any call to writeln will result in segfault on ubuntu (but on osx I don't have this problem) with git checkout 2.064 instead of git checkout master, things work. In my setup (Ubuntu 12.04.3 LTS, x86_64), compiled programs segfault somewhere during C runtime initialization. 2.064 works.
Re: D Programmer Jobs at Sociomantic Labs
On Monday, 4 November 2013 at 17:11:08 UTC, Dicebot wrote: On Monday, 4 November 2013 at 16:22:52 UTC, Gary Willoughby wrote: Something like C or D (i'd opt for D) should be any devs first language. Simply to educate them in the basics. In Soviet Russia you do assembly in primary school :) Hehe, that's what I did. For http://en.wikipedia.org/wiki/KR580VM80A, an i8080 replica. Actually, I managed to write my first working assembly program by POKEing machine codes form BASIC. The machine didn't have a display, so I was entering the commands by touch. Unforgettable experience.
Re: D Programmer Jobs at Sociomantic Labs
On Friday, 1 November 2013 at 17:38:01 UTC, Marenz wrote: Hey D Programmers, so, we at Sociomantic Labs are once again (or still) looking for D-Developers in Berlin. And lots of them. Currently still D1, but the process to change to D2 is initiated. How can one still program in D1? ;) You can read more about it here: https://www.sociomantic.com/jobs/d-software-developer/#.UnPl4Xh385Y You can contact me anytime if you have specific questions. You can find me in the IRC #d channel as Marenz, M4renz or Suprano or you just send me an email. cheers, --Mathias
Re: D vs Go in real life
On Saturday, 30 November 2013 at 21:14:53 UTC, Max Samukha wrote: On Friday, 22 November 2013 at 23:08:38 UTC, Andrei Alexandrescu wrote: On 11/22/13 1:49 PM, Max Samukha wrote: On Wednesday, 6 November 2013 at 19:42:21 UTC, Andrei Alexandrescu wrote: Go's team was unable to add generics to the language. Not adding generics was Go's deliberate decision. http://golang.org/doc/faq#generics "We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it." Ok, I stand corrected. For that matter, D got its type system all wrong compared to Haskell. So why won't we all move there? Move where? Tried to implement a GADT in D? To clarify: "Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly." Can you implement a GADT in D as "smoothly" as in Haskell?
Re: D vs Go in real life
On Friday, 22 November 2013 at 23:08:38 UTC, Andrei Alexandrescu wrote: On 11/22/13 1:49 PM, Max Samukha wrote: On Wednesday, 6 November 2013 at 19:42:21 UTC, Andrei Alexandrescu wrote: Go's team was unable to add generics to the language. Not adding generics was Go's deliberate decision. http://golang.org/doc/faq#generics "We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it." Ok, I stand corrected. For that matter, D got its type system all wrong compared to Haskell. So why won't we all move there? Move where? Tried to implement a GADT in D? Andrei
Re: What’s Wrong with OOP and FP
On Tuesday, 12 November 2013 at 11:09:24 UTC, Luís Marques wrote: I think you will be pleased with the argument, given D's philosophy: https://yinwang0.wordpress.com/2013/11/09/oop-fp/ “functions are also objects”. Yes, they are. http://en.wikipedia.org/wiki/Category_theory
Re: Delegate is left with a destroyed stack object
On Wednesday, 30 October 2013 at 12:17:29 UTC, Max Samukha wrote: So D managed to mess up closures, too. And that's after years of countless complaints about the same issue in JS! And please no misguided arguments like http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closing-over-the-loop-variable-considered-harmful.aspx.
Re: Delegate is left with a destroyed stack object
On Wednesday, 30 October 2013 at 09:56:08 UTC, David Nadlinger
wrote:
One other place where this tends to crop is for code involving
loop variables, but while the behavior might be unexpected to
some, discussion has made clear that the code works as intended:
---
void main() {
import std.stdio;
void delegate()[] dgs;
foreach (i; 0 .. 5) dgs ~= { writeln(i); };
foreach (dg; dgs) dg();
}
---
If structs behaved like you want them to, the snippet would
(have to) print 0, 1, 2, 3, 4 as well, and tht's definitely too
big a language change to consider at this stage.
David
So D managed to mess up closures, too. And that's after years of
countless complaints about the same issue in JS!
Re: Empty VS null array?
On Friday, 25 October 2013 at 11:41:38 UTC, Kagamin wrote: On Monday, 21 October 2013 at 10:33:01 UTC, Regan Heath wrote: null strings are no different to null class references, they're not a special case. True. That's an implementation detail which has no meaning for business logic. When implementation deviates from business logic, one ends up fixing the implementation details everywhere in order to implement business logic. That's why string.IsNullOrEmpty is used. That's not an implementation detail. Whether "null" is in the set of values of a string type and whether it is identical to "empty" are fundamental properties of that type. If you define the string type to include "null", then "null" should be either identical to "empty" in *all cases* or distinct from that in all cases. D chose to fuse "null" and "empty" together in an inconsistent manner, which is a mistake. If we include "null" in the set, then either the [] literal should be non-null (and "null" and "empty" properly disjoint), or "null" and "empty" should always represent the same value. If we exclude it - *then* "null" becomes an implementation detail and should be dealt with only via .ptr. People seem to have this odd idea that null is somehow an invalid state for a string /reference/ (c# strings are reference types), it's not. That's the very problem: null and empty are valid states and must be treated equally as "no data", but they can't for purely technical reasons. Whether they are valid states is irrelevant. What matters is whether they represent identical values. In D, they are unhealthily mixed.
Re: Qt bindings for D
On Tuesday, 22 October 2013 at 21:01:49 UTC, w0rp wrote:
On Wednesday, 16 October 2013 at 09:56:21 UTC, Max Samukha
wrote:
On Wednesday, 16 October 2013 at 07:25:08 UTC, w0rp wrote:
On Wednesday, 16 October 2013 at 06:53:24 UTC, Jacob Carlborg
wrote:
In D, using the GC, you can call GC.addRoot to avoid that
problem.
Yes, I was thinking of using core.memory stuff to stop things
from being collected, or perhaps scan inside Qt memory. For
instance, you could store a class pointer inside of a QObject
with setProperty. One option is to have QObject in D hold an
array of pointers for keeping references to children, etc.
There are some tricky parts.
---
// Okay, this is a root object, when do we collect this?
auto widget = new QWidget();
// This is just a free object, not attached to anything.
// Clearly we can collect this.
auto label = new QLabel("Hello!");
auto layout = new QHBoxLayout;
layout.addWidget(label);
// Wait, now label implicitly becomes a child object of
widget.
// its memory is now managed by that, so when do we collect
it?
widget.setLayout(layout);
// Does this work?
assert(label.parent is widget);
---
So in other words, I haven't yet reached a point where I
think, "Yes, I have covered every case and I'm happy."
I've ended up with a system that would not allocate Qt objects
on the GC heap at all:
// This would be destroyed at the end of the scope,
auto widget = scoped!QWidget;
// Or, if we allocate the object on heap, we should care
// to destroy it unless Qt takes ownership at some point after
// construction.
auto widget = make!QWidget;
...
dispose(widget);
auto widget = make!QLabel("Hello!");
auto layout = make!QHBoxLayout;
// Safe to pass ownership to parent because no GC is involved.
layout.addWidget(label);
// ditto
widget.setLayout(layout);
// This would work because references to polymorphic Qt
objects are
// implemented as tagged pointers, and in this case
// both references would point to the same C++ object.
assert(label.parent is widget);
In other words, you manage memory the same way you do in Qt.
Advantages:
- Noticeable simplification of the generator and bindings.
- Performance - no redundant copies, hash lookups, etc.
- Fewer problems with multithreading.
Disadvantages:
- You have to be as careful about memory management as you are
in Qt.
- Implementation requires a debugged D compiler, which does
not exist yet. :)
An interesting endeavor would be to figure out whether things
could be simplified with "interface(C++)".
There's one very big disadvantage there, I think. It looks
ugly. I do have to point out that this opinion somewhat stems
from me just not liking 'scoped.' I think the above example
just makes me think, "The best solution has not yet been
found." Again, I don't know what that is yet.
There is no best solution. You have to trade off. For my purpose,
that was the best option, which was maintainable, performant and
correct (apparenty). I do not care much about how it looks, given
that it is concise. Some don't like the look of chinese
hieroglyphs or black skin. I for one don't see much beauty in
"new". Anyway, the project QtD was intended for was cancelled
long ago, so you are free to transform it according to yor vision.
Re: Safe mode in D?
On Saturday, 19 October 2013 at 10:50:42 UTC, Maxim Fomin wrote: OK, you can remove extern(c) trick (however, it is not clear, why it shouldn't be counted as a type system hole) and you still have "reflection hole". I came up with the code in response to Andrei who said that constructor control flow is "primitive but quite adequate" and which "is already implemented and works". What "primitive but quite adequate" does mean is subjective, but it does not really prevent from what it is suppose to prevent. Of course in this case you do not corrupt memory or write to immutable (I am telling this for the third time). The point was made why would you have such constraint if it is easily avoidable? How much sense is in the constraint which does not provide real value (except probably as an exercise in implementing abstract programming theories from academia) nor is properly reinforced? The question is what it takes to close every possible hole. .NET designers apparently decided not to close the reflection hole because the cost (in various senses) would be too high.
Re: Empty VS null array?
On Saturday, 19 October 2013 at 12:04:43 UTC, Kagamin wrote: On Friday, 18 October 2013 at 17:59:17 UTC, Max Samukha wrote: On Friday, 18 October 2013 at 16:55:19 UTC, Andrei Alexandrescu wrote: Fair point. I just gave one possible alternative out of many. Thing is, relying on client code to distinguish subtleties between empty and null strings is fraught with dangers. Andrei I agree. Thinking about your variant of readln - it's ok to use [] as the value indicating EOF, since it is not included in the value set of type "line" as you define it. No, if the last line is empty, it has no new line character(s) at the end, and is as empty, as it can get. Right. Then readln is broken.
Re: Safe mode in D?
On Saturday, 19 October 2013 at 08:45:05 UTC, Maxim Fomin wrote: Actually aggregate name of collection was "(collection of memory errors, type system breakages and other cases to shoot your foot provided by bugzilla issues, me and other people)". And we are back to square one - misusing extern(C) and reflection to call the constructor as you showed in #13 does not belong in that collection.
Re: Safe mode in D?
On Saturday, 19 October 2013 at 08:38:52 UTC, Maxim Fomin wrote: On Saturday, 19 October 2013 at 08:21:18 UTC, Max Samukha wrote: On Saturday, 19 October 2013 at 07:39:36 UTC, Maxim Fomin wrote: This is wrong. Compare safe D and C# in safe, checked mode (I suspect you tried to sell unchecked mode, unmanaged pointers and C++ code invocation as unsafe C# - there are also unsafe features like casts or unions in unsafe D, but this is irrelevant, we are comparing safe mode) and try to come up with examples of memory corruption in C#. At least I showed 4 cases of memory corruption, 4 cases of broken immutable, 2 cases of broken purity in safe D without casts, unions and unchekeced attributes of extern C (which is also hole in type system). So far, you provided only resentment that D was negatively compred with C#. I would agree if: 1. most of the cases you provided were not compiler bugs. Wrong. Most of cases presented are frontend bugs, since all three known compilers share the same frontend, they are also buggy. In any case, D is not in a position like C, where there are plenty of compilers. Most are stack to dmd/gdc/ldc. So, there is no way to escape from this "just compiler bugs". You can throw "it is compiler bug, but not language issue" into the trash (please also D butthurt). Note that you are making similar assumptions about the state of my butt as I did about your dissatisfaction. 2. C#'s safety didn't have a price. I didn't heard that C# would advertise itself as having speed 'more than C' or any nonsense like D promises about its safety. I haven't heard D ever advertised itself as "faster than C". I heard that immutability/purity provides an opportunity for optimizations not possible in C, and those opportunities have not been realized yet. 3. C# had immutable, pure, etc. But features which it does care to provide, are not bunch of holes in type system. This is so opposite to D with strings, shared, AAs, etc. What's wrong with D's strings?
Re: Safe mode in D?
On Saturday, 19 October 2013 at 08:25:58 UTC, Maxim Fomin wrote: On Saturday, 19 October 2013 at 07:42:24 UTC, Max Samukha wrote: On Saturday, 19 October 2013 at 07:24:49 UTC, Maxim Fomin wrote: Actual definition of safity in D is "Safe functions are functions that are statically checked to exhibit no possibility of undefined behavior. Undefined behavior is often used as a vector for malicious attacks. " I provided many cases where this does not happen. I know the definition. Aren't we discussing a different matter - your dissatisfaction with the fact that D's control flow analysis does not prevent indirect calls to the constructor? No. Topic of the thread is Safe D. The point was made that D's safe mode is not safe at all. Constructor invocation is a spin-off of the topic. It's you who made that spin-off, trying to foist it in as yet another example of D's unsafety. I was replying to that. By the way, no dissatisfaction here, as I don't by D premises at all. You sounded dissatisfied.
Re: Safe mode in D?
On Saturday, 19 October 2013 at 07:39:36 UTC, Maxim Fomin wrote: This is wrong. Compare safe D and C# in safe, checked mode (I suspect you tried to sell unchecked mode, unmanaged pointers and C++ code invocation as unsafe C# - there are also unsafe features like casts or unions in unsafe D, but this is irrelevant, we are comparing safe mode) and try to come up with examples of memory corruption in C#. At least I showed 4 cases of memory corruption, 4 cases of broken immutable, 2 cases of broken purity in safe D without casts, unions and unchekeced attributes of extern C (which is also hole in type system). So far, you provided only resentment that D was negatively compred with C#. I would agree if: 1. most of the cases you provided were not compiler bugs. 2. C#'s safety didn't have a price. 3. C# had immutable, pure, etc.
Re: Safe mode in D?
On Saturday, 19 October 2013 at 07:22:35 UTC, Paulo Pinto wrote: That is why they have to : - be marked unsafe - be allowed by the security manager In D's case it is no different, such code is only to be allowed in @system code and partilly in @thrusted. -- Paulo I understand. However, the case under discussion is about D failing to catch invalid constructor calls. In that regard, granted the C extern is marked @trusted, D is no different than C#.
Re: Safe mode in D?
On Saturday, 19 October 2013 at 07:24:49 UTC, Maxim Fomin wrote: Actual definition of safity in D is "Safe functions are functions that are statically checked to exhibit no possibility of undefined behavior. Undefined behavior is often used as a vector for malicious attacks. " I provided many cases where this does not happen. I know the definition. Aren't we discussing a different matter - your dissatisfaction with the fact that D's control flow analysis does not prevent indirect calls to the constructor?
Re: Safe mode in D?
On Saturday, 19 October 2013 at 07:02:21 UTC, Paulo Pinto wrote: Am 19.10.2013 08:58, schrieb Max Samukha: On Saturday, 19 October 2013 at 06:24:00 UTC, Paulo Pinto wrote: There is nothing unsafe about this code snippet. Sure. There is nothing unsafe in misusing __traits and extern(C) as well. There is if the result is - memory corruption - memory leaks no longer visible to the GC - program crash - ... No problem, since that was the programmer's explicit purpose. C# provides a ton of backdoors that could lead to what you mentioned in your list.
Re: Safe mode in D?
On Saturday, 19 October 2013 at 06:24:00 UTC, Paulo Pinto wrote: There is nothing unsafe about this code snippet. Sure. There is nothing unsafe in misusing __traits and extern(C) as well.
Re: Safe mode in D?
On Friday, 18 October 2013 at 23:03:42 UTC, ProgrammingGhost wrote: Whats 'wrong' with this code? Nothing, that's the point. Just like with __traits(getOverloads, this, "__ctor")[0](i). In my world, safety features of a language are meant to help a fairly reasonable programmer avoid accidental mistakes. Misusing reflection or C interface is not an accidental mistake.
Re: Safe mode in D?
On Friday, 18 October 2013 at 20:03:22 UTC, Maxim Fomin wrote:
(By the way, I don't see why the code above provoked you to C#
talks).
Because you:
1) Mentioned C# as a safer alternative to D.
2) Are using reflection to demonstrate D's unsafety.
Try this:
using System;
using System.Reflection;
namespace test
{
class A
{
public int x;
public A()
{
x += 1;
}
}
class App
{
public static void Main (string[] args)
{
var a = new A();
var ctor = a.GetType().GetConstructor(new Type[] {});
ctor.Invoke(a, new object[] {});
ctor.Invoke(a, new object[] {});
Console.Write(a.x);
}
}
}
Re: Safe mode in D?
On Friday, 18 October 2013 at 19:28:35 UTC, Maxim Fomin wrote:
On Friday, 18 October 2013 at 18:59:46 UTC, Andrei Alexandrescu
wrote:
I think one good compromise is to stick with the exact amount
of flow control we currently have in constructors (which is
primitive but quite adequate), and use that creatively. It's
already implemented and works, so the implementation costs of
applying it to other cases should be low.
Andrei
Do you mean preventing calling constructor (from another
constructor) within one control branch? May be this will be
case #13.
import std.stdio;
extern(C) void _D4main1A6__ctorMFiZC4main1A(A a, int i);
class A
{
this(int i) { writeln("reached"); }
this()
{
int i = 1;
//if (i)
// this(i); // Error: one path skips constructor
if (i)
_D4main1A6__ctorMFiZC4main1A(this, i);
if (i)
auto dg = __traits(getOverloads, this, "__ctor")[0](i);
}
}
void main()
{
new A;
}
Wanna talk about what can be done with reflection in "safe" C#?
Re: Empty VS null array?
On Friday, 18 October 2013 at 16:55:19 UTC, Andrei Alexandrescu wrote: Fair point. I just gave one possible alternative out of many. Thing is, relying on client code to distinguish subtleties between empty and null strings is fraught with dangers. Andrei I agree. Thinking about your variant of readln - it's ok to use [] as the value indicating EOF, since it is not included in the value set of type "line" as you define it. But generally, neither cast(T[])[] nor cast(T[])null should be used like that, because both of them are in the set of T[]'s values, i.e. a generic stream returning [] to signify its end would be a bad idea - that should be either a side effect or a value outside T[]'s set. Hm, I've just said nothing with many words. Never mind.
Re: Empty VS null array?
On Friday, 18 October 2013 at 15:42:56 UTC, Andrei Alexandrescu wrote: On 10/18/13 3:44 AM, Regan Heath wrote: On Fri, 18 Oct 2013 00:32:46 +0100, H. S. Teoh wrote: On Fri, Oct 18, 2013 at 01:27:33AM +0200, Adam D. Ruppe wrote: On Thursday, 17 October 2013 at 23:12:03 UTC, ProgrammingGhost wrote: >is null still treats [] as null. blah, you're right. It will at least distinguish it from an empty slice though (like arr[$..$]). I don't think there's any way to tell [] from null except typeof(null) at all. At runtime they're both the same: no contents, so null pointer and zero length. I think it's a mistake to rely on the distinction between null and non-null but empty arrays in D. They should be regarded as implementation details that user code shouldn't depend on. If you need to distinguish between arrays that are empty and arrays that are null, consider using Nullable!(T[]) instead. This comes up time and again. The use of, and ability to distinguish empty from null is very useful. I disagree. Yes, you run the risk of things like null pointer exceptions etc, but we have that risk now without the reward of being able to distinguish these cases. Take this simple design: string readline(); This function would like to be able to: - return null for EOF - return [] for a blank line That's bad API design, pure and simple. The function should e.g. return the string including the line terminator, and only return an empty (or null) string upon EOF. Andrei *That's* bad API design. readln should be symmetrical to writeln, not write. And about preserving the exact representation of new lines, readln/writeln shouldn't preserve that, pure and simple.
Re: add -allinst compiler switch
On Friday, 18 October 2013 at 07:17:12 UTC, Walter Bright wrote: Explained here: http://d.puremagic.com/issues/show_bug.cgi?id=11284 It's a bit complicated, and important. BTW, I hate the name of the switch, but haven't thought of anything better. A good start would be to have the issues thoroughly explained in the documentation. As far as I know, no article on templates mentions how they are actually compiled.
Re: Eloquently sums up my feelings about the disadvantages of dynamic typing
On Wednesday, 16 October 2013 at 20:00:45 UTC, Walter Bright wrote: On 10/16/2013 8:37 AM, Sean Kelly wrote: I'm reasonably okay with dynamic languages so long as you can require a variable to be declared before it's used. Those that implicitly declare on first assignment are a nightmare however. I once spent an entire day debugging a Lua app that turned out to be broken because of a typo in an assignment. Never again. Implicit declaration is such a bad idea; I wonder why it keeps reappearing in every new dynamic language du jour. Hail CoffeeScript!
Re: Qt bindings for D
On Wednesday, 16 October 2013 at 07:25:08 UTC, w0rp wrote:
On Wednesday, 16 October 2013 at 06:53:24 UTC, Jacob Carlborg
wrote:
In D, using the GC, you can call GC.addRoot to avoid that
problem.
Yes, I was thinking of using core.memory stuff to stop things
from being collected, or perhaps scan inside Qt memory. For
instance, you could store a class pointer inside of a QObject
with setProperty. One option is to have QObject in D hold an
array of pointers for keeping references to children, etc.
There are some tricky parts.
---
// Okay, this is a root object, when do we collect this?
auto widget = new QWidget();
// This is just a free object, not attached to anything.
// Clearly we can collect this.
auto label = new QLabel("Hello!");
auto layout = new QHBoxLayout;
layout.addWidget(label);
// Wait, now label implicitly becomes a child object of widget.
// its memory is now managed by that, so when do we collect it?
widget.setLayout(layout);
// Does this work?
assert(label.parent is widget);
---
So in other words, I haven't yet reached a point where I think,
"Yes, I have covered every case and I'm happy."
I've ended up with a system that would not allocate Qt objects on
the GC heap at all:
// This would be destroyed at the end of the scope,
auto widget = scoped!QWidget;
// Or, if we allocate the object on heap, we should care
// to destroy it unless Qt takes ownership at some point after
// construction.
auto widget = make!QWidget;
...
dispose(widget);
auto widget = make!QLabel("Hello!");
auto layout = make!QHBoxLayout;
// Safe to pass ownership to parent because no GC is involved.
layout.addWidget(label);
// ditto
widget.setLayout(layout);
// This would work because references to polymorphic Qt objects
are
// implemented as tagged pointers, and in this case
// both references would point to the same C++ object.
assert(label.parent is widget);
In other words, you manage memory the same way you do in Qt.
Advantages:
- Noticeable simplification of the generator and bindings.
- Performance - no redundant copies, hash lookups, etc.
- Fewer problems with multithreading.
Disadvantages:
- You have to be as careful about memory management as you are in
Qt.
- Implementation requires a debugged D compiler, which does not
exist yet. :)
An interesting endeavor would be to figure out whether things
could be simplified with "interface(C++)".
Re: Qt bindings for D
On Monday, 14 October 2013 at 11:35:05 UTC, Jacob Carlborg wrote: On 2013-10-14 11:03, Max Samukha wrote: I recommend to dump it and start from scratch. A clang-based generator would be an interesting option to explore. Or, if you want to preserve your sanity, just write Qt applications in C++/QML. I already have a Clang based tool, DStep, but that's only for C and Objective-C. It could be extended to support C++ as well. https://github.com/jacob-carlborg/dstep Nice! That may come in handy some day.
Re: Qt bindings for D
On Monday, 14 October 2013 at 09:45:18 UTC, Abdulhaq wrote: I recommend to dump it and start from scratch. A clang-based generator would be an interesting option to explore. Or, if you want to preserve your sanity, just write Qt applications in C++/QML. Hi Max, so why dump it? I can see a few reasons why you might propose that: 1) You think it's a dead end because QtJambi is dead, so it would be problematic to move it forward with new versions of Qt That is one reason. Also, QtJambi is based on a limited and outdated C++ parser, and we had problems getting necessary information from it. When Qt moves to C++11, the situation will get worse. So I think it is reasonable to switch to clang soon. 2) There are some problems with the architecture of the binding that you're aware of that would prevent it from working reliably For (1), I think even only having 4.8 is still a real asset. I don't know the code base really well (but spent a fair amount of time with it, and know the PyQt technology fairly well too) so can't speak to (2) but if you had specific concerns it would be very interesting to know what they were. From my testing it seems to me that a lot is working, enough to write useful GUIs in it - tell me what I'm missing (a lot, I know, but is anything really fatally flawed)? Well, you can use the bindings for simple short-living utilities if you don't mind occasional memory leaks and crashes. Long story short, D allows for two approaches to bindings like QtD: 1. The traditional one is to allocate "shells" on GC heap and have a set of manually specified rules for ownership transfers and reference count adjustments. 2. The other is more interesting - abandon the idea of reference/ownership annotations and go with semi-automatic memory management as it is in Qt, with no reliance on the GC. At some point I wanted to switch to 2 completely, so QtD is somewhere between 1 and 2, quite a mess.
Re: Qt bindings for D
On Sunday, 13 October 2013 at 21:28:20 UTC, David Nadlinger wrote: On Sunday, 13 October 2013 at 20:52:31 UTC, Abdulhaq wrote: On Sunday, 13 October 2013 at 20:41:01 UTC, michaelc37 wrote: https://bitbucket.org/michaelc37/qtd-experimental […] Hah, sounds like we did exactly the same thing :-) ! I haven't uploaded the code anywhere yet, I was waiting to see if anyone was interested... Okay, so what do you guys think about starting an "unofficial-official" (I can't speak for Eldar and Max, the main authors of QtD, but you have my blessing as a contributor of the project) QtD revival repository on GitHub to coordinate the efforts? I can set you up with access to github.com/qtd if you want. David I recommend to dump it and start from scratch. A clang-based generator would be an interesting option to explore. Or, if you want to preserve your sanity, just write Qt applications in C++/QML.
Re: ctrl+c and destructors
On Wednesday, 2 October 2013 at 02:30:42 UTC, Walter Bright wrote: Right. A null pointer dereference is a logic bug in your program, and hence the program needs to stop immediately, not execute "cleanup" code. If there's one notion I'd like to terminate with prejudice, it's the notion that a running program can "recover" from bugs in itself. That famous prejudice of yours :). As always, it depends. The application can't "recover" but it can give the user an opportunity to (partially) recover his work. For example, I appreciated the fact that Cubase/Nuendo often continued execution after a poorly debugged in-process plugin segfaulted. I do not know exactly what cleanup procedure the application executed on the inconsistent state but most of the time I was able to recover it completely.
Re: Bartosz Milewski seems to like D more than C++ now :)
On Tuesday, 24 September 2013 at 14:24:48 UTC, renoX wrote: On Tuesday, 24 September 2013 at 14:15:12 UTC, Max Samukha wrote: [cut] I think that -> is neither unnecessary nor noise. After having played with Haskell for a while, I actually find the syntax of D unnecessarily redundant. Oh, D is hardly a good example for syntax! Better than C++ doesn't say much.. Ok. That said, I don't see how one could prefer 'a -> b -> c' over 'a,b -> c' in this case.. In case of Haskell, it is not a matter of preference. The syntax follows from the language semantics and I don't see how it can be different and better at the same time. (a, b) -> c means a function that maps a pair to an object (the same as ((,) a b) -> c). a -> b -> c, parens around b -> c omitted thanks to right associativity, means a function that maps an object to a function. How does a, b -> c fits in this picture? This is not the only 'visual noise' in Haskell: for example Idris replaced '::' by ':', a good change IMHO. That is probably because ':' is the list append operator already. Yes, it's the other way round in Idris, but for once I prefer D's operator '~': list appending is common enough that it deserves a proper operator not a doubled one :: like in Idris or other (Scala?). Sadly, I don't know Idris or Scala. Now we are talking about subjective preferences, which is an exercise in futility. :) renoX
Re: Bartosz Milewski seems to like D more than C++ now :)
On Tuesday, 24 September 2013 at 13:46:16 UTC, renoX wrote: On Tuesday, 24 September 2013 at 13:04:10 UTC, deadalnix wrote: On Tuesday, 24 September 2013 at 11:32:18 UTC, renoX wrote: I'm not sure you understood my point: a 'normal' function takes inputS and produce an output, in the notation: a,b->c you can clearly see the inputS and the output with a minimum of 'syntax noise' around them. In the notation a -> b -> c, the 'syntax noise' is bigger (those arrows between the input parameters are much more 'heavy on the eye' than a quote), and what does it bring? Nothing.. It's the notation which makes the function type less readable which I consider a mistake. You are putting artificial barrier here. a -> b -> c is a function that take a as parameter and return a function that take b as parameter and return c. The concept of multiple parameters and stuff like that exists only in your mind. You try to map a concept you have in your mind in the language when it DO NOT exist in the language. A language is not something set in stone! If the design of a language requires unecessary visual noise, I dislike it, this is not as bad as Lisp, but it is still suboptimal. I think that -> is neither unnecessary nor noise. After having played with Haskell for a while, I actually find the syntax of D unnecessarily redundant. This is not the only 'visual noise' in Haskell: for example Idris replaced '::' by ':', a good change IMHO. That is probably because ':' is the list append operator already. renoX
Re: Bartosz Milewski seems to like D more than C++ now :)
On Tuesday, 24 September 2013 at 12:09:28 UTC, Szymon Gatner wrote: On Tuesday, 24 September 2013 at 12:06:22 UTC, Max Samukha wrote: A 'normal' function in Haskell takes exactly one object and returns exactly one object. a -> b -> c is actually a -> (b -> c) because -> is right-associative. It's perfectly readable for people in the Haskell subculture. You'll have hard time convincing them otherwise :) Isn't function application in Haskell left-associative? (I might be confusing terms as I am just learning it) So am I. Function application is left-associative. (f a b) is the equivalent of ((f a) b). Arrow in the lambda types is right-associative. If you mentally add parens, then things like (a -> b -> c) -> [a] -> [b] -> [c] look less intimidating - (a -> (b -> c)) -> ([a] -> ([b] -> [c])). Well, they don't. But at least you can make some sense of them, sometimes. They definitely don't look more intimidating than D's template instantiations.
Re: Bartosz Milewski seems to like D more than C++ now :)
On Tuesday, 24 September 2013 at 11:32:18 UTC, renoX wrote: On Tuesday, 24 September 2013 at 09:15:37 UTC, Timon Gehr wrote: On 09/23/2013 02:08 PM, renoX wrote: On Friday, 20 September 2013 at 15:23:20 UTC, Paulo Pinto wrote: Am 20.09.2013 16:24, schrieb renoX: That said, he made the same mistake as Haskell's authors: currying is a *mathematical detail* which shouldn't obscure function type: 'f: a->b->c' is less readable than 'f: a,b->c'. renoX That is standard in all languages of the ML family, not only Haskell. I know, but 'standard' doesn't mean that it is a good idea.. renoX Neither does 'mathematical detail' mean it is obscure, unreadable or a mistake as you seem to imply. I'm not sure you understood my point: a 'normal' function takes inputS and produce an output, in the notation: a,b->c you can clearly see the inputS and the output with a minimum of 'syntax noise' around them. In the notation a -> b -> c, the 'syntax noise' is bigger (those arrows between the input parameters are much more 'heavy on the eye' than a quote), and what does it bring? Nothing.. It's the notation which makes the function type less readable which I consider a mistake. renoX A 'normal' function in Haskell takes exactly one object and returns exactly one object. a -> b -> c is actually a -> (b -> c) because -> is right-associative. It's perfectly readable for people in the Haskell subculture. You'll have hard time convincing them otherwise :)
Re: A proper language comparison...
On Friday, 26 July 2013 at 05:13:37 UTC, Walter Bright wrote: On 7/25/2013 7:19 PM, bearophile wrote: You don't want a stack overflow in the code that controls your car brakes (this is not a totally invented example). Sadly, it isn't: http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/ Software controlled brakes with no override? Madness! Only death statistics for a sufficiently long usage period could tell whether software + override is safer than purely software. Note that software + override is significantly more complex, which means a decrease in reliability of the system in whole.
Re: Time to destroy Walter: breaking modules into packages
On Thursday, 6 June 2013 at 06:26:17 UTC, Jonathan M Davis wrote: On Thursday, June 06, 2013 08:09:38 Max Samukha wrote: On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote: > But I believe that package level access only works on the > same > level, so you > couldn't have separate modules for compressing and > decompressing as was being > suggested. 'package' should be fixed so that 'package' declarations are accessible within nested packages. Well, it _is_ debatable as to whether that's desirable or not. With the current behavior, you can have a package which shares stuff within itself but not with its sub-packages, but there's no way to share with the sub-packages without making the symbols public; whereas if sub-packages have access to their parent packages' package functions, then packages _can_ share with their sub-packages, but they can't restrict anything to just the package. Both ways have their pros and cons. I don't know which is ultimately better. There is not much to debate. Get your hands dirty with a real project having more than two levels of packages and you'll see that the first is ultimately better. While limiting 'package' to one level may be sometimes desirable, forcing package-private members to be world-public is highly undesirable. As a package author I can tolerate loose access policies within a package tree that *I* control but I definitely don't want to expose to the user of my package what he shouldn't have access to.
Re: Time to destroy Walter: breaking modules into packages
On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote: But I believe that package level access only works on the same level, so you couldn't have separate modules for compressing and decompressing as was being suggested. 'package' should be fixed so that 'package' declarations are accessible within nested packages.
Re: Slow performance compared to C++, ideas?
On Wednesday, 5 June 2013 at 22:03:05 UTC, Walter Bright wrote: We can do an upgrade path as follows: 1. Introduce 'virtual' storage class. 'virtual' not only means a method is virtual, but it is an *introducing* virtual, i.e. it starts a new vtbl[] entry even if there's a virtual of the same name in the base classes. This means that functions marked 'virtual' do not override functions marked 'virtual'. Note that 'new' modifier in C# is applicable not only to virtual methods (MS calls it "name hiding"). Not using 'new' when hiding a public member is a warning. References: http://msdn.microsoft.com/en-us/library/vstudio/435f1dw2.aspx http://msdn.microsoft.com/en-us/library/aa691135(v=vs.71).aspx http://msdn.microsoft.com/en-us/library/aa645767(v=vs.71).aspx Some points from limited personal experience: 1. Private final methods in D can hide base methods. That's *useful*. Don't try to change that. 2. Public final methods in D cannot be hidden. That's been a problem for me and other people. 3. I've seen 'new' on final methods in C# in practice and used it myself. I've never seen virtual methods being hidden and never needed that myself. 2. Issue a warning if a function overrides a function that is not marked 'virtual'. 3. Deprecate (2). 4. Error (2), and make non-virtual the default.
Re: std.compress
On Wednesday, 5 June 2013 at 06:18:54 UTC, Walter Bright wrote: On 6/4/2013 9:44 PM, Max Samukha wrote: On Tuesday, 4 June 2013 at 18:46:49 UTC, Walter Bright wrote: On 6/4/2013 11:43 AM, Timothee Cour wrote: writing generic code. same reason as why we prefer: auto y=to!double(x) over auto y=to_double(x); The situations aren't comparable. The to!double case is parameterizing with a type, the compress one is not. Secondly, compress(lzw) does ABSOLUTELY NOTHING but turn around and call lzw. It adds nothing. That "absolutely" based on limited personal experience is the biggest D's problem. I've seen an awful lot of abstractions over the years that provided zero value. I understand. But I've also seen a lot of abstractions over the years that seemed useless initially but were discovered to be extremely useful later (Bayes theorem is an example - it took 300 years to find a concrete use for it). So "a compelling use case" is not a sufficient criterion for evaluating usefulness of abstractions. You need to provide a compelling use case to justify another layer of complexity. "generic code" is not a compelling use case. It's already generic. Note how these components are to be used: src.lzwCompress.copy(dst); Your proposal is: src.compress(lzw).copy(dst); I.e. zero value, as so far all compress() does is call lzw(). That's not my proposal. Honestly I didn't even take a close look at it. I just felt like it was time to attack you - there is an explicit permission for casual trolling you gave. The whole point of range-based pipeline programming is you can just plug in different components. There is no demonstrated use case for adding another layer. Ok. I am actually wrong in saying it has zero value. It has negative value :-) In this particular case, maybe.
Re: std.compress
On Wednesday, 5 June 2013 at 04:54:46 UTC, Andrei Alexandrescu wrote: On 6/5/13 12:44 AM, Max Samukha wrote: On Tuesday, 4 June 2013 at 18:46:49 UTC, Walter Bright wrote: On 6/4/2013 11:43 AM, Timothee Cour wrote: writing generic code. same reason as why we prefer: auto y=to!double(x) over auto y=to_double(x); The situations aren't comparable. The to!double case is parameterizing with a type, the compress one is not. Secondly, compress(lzw) does ABSOLUTELY NOTHING but turn around and call lzw. It adds nothing. That "absolutely" based on limited personal experience is the biggest D's problem. It's a point, but "biggest" is also kind of too much and based on limited personal experience :o). Andrei Yeah, I noticed that.
Re: DIP22 - private symbol visibility
On Tuesday, 4 June 2013 at 21:32:32 UTC, Timon Gehr wrote: On 06/04/2013 08:10 PM, Max Samukha wrote: On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote: http://wiki.dlang.org/DIP22 "I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea" How is that useless? Any non-trivial OOP code (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions) swarm with protected methods, and rightfully so. How would one restrict access to members that are not part of public interface but should be accessible to the derived classes? I don't think it is possible. protected methods are part of the public interface, since inheritance cannot be restricted selectively. I don't quite understand. Could you explain?
Re: DIP22 - private symbol visibility
On Tuesday, 4 June 2013 at 18:33:21 UTC, Steven Schveighoffer wrote: Since protected access is actually ESSENTIAL in OOP (at least, some form of virtual non-public function access, private is not virtual, so it would be disastrous to remove protected), I am wondering whether Walter really meant "package", as that has very little utility. Care to answer, Walter? -Steve 'package' cannot possibly solve the problem because the protected members should be accessible outside of the defining package.
Re: std.compress
On Tuesday, 4 June 2013 at 18:46:49 UTC, Walter Bright wrote: On 6/4/2013 11:43 AM, Timothee Cour wrote: writing generic code. same reason as why we prefer: auto y=to!double(x) over auto y=to_double(x); The situations aren't comparable. The to!double case is parameterizing with a type, the compress one is not. Secondly, compress(lzw) does ABSOLUTELY NOTHING but turn around and call lzw. It adds nothing. That "absolutely" based on limited personal experience is the biggest D's problem.
Re: DIP22 - private symbol visibility
On Tuesday, 4 June 2013 at 17:39:05 UTC, Peter Alexander wrote: http://wiki.dlang.org/DIP22 "I'd also throw in getting rid of the "protected" access attribute completely, as I've seen debate over that being a useless idea" How is that useless? Any non-trivial OOP code (http://qt-project.org/doc/qt-4.8/qabstractitemview.html#protected-functions) swarm with protected methods, and rightfully so. How would one restrict access to members that are not part of public interface but should be accessible to the derived classes?
Re: Slow performance compared to C++, ideas?
On Tuesday, 4 June 2013 at 00:19:39 UTC, Manu wrote:
But this is a practical solution. The only counter-proposal
I've heard is
Andrei's 'all methods use ufcs' idea, but I think that one
would be a much
harder sell to the community. I'm certainly not convinced.
It would be hard to sell for at least one reason - protected
non-virtual methods are quite common:
module a;
class A
{
}
// should be accessible to derived classes
// and is not part of A's public interface
private void foo(A this_);
module b;
import a;
class B : A
{
virtual void bar()
{
foo(); // How?
}
}
Re: Low-Lock Singletons In D
On Friday, 24 May 2013 at 14:03:24 UTC, bearophile wrote: Max Samukha: The question is what should be the result of: Nullable(int*)? Nullable!(Nullable!T)? Forbidden (like in C#)? Aliased to the source type? A distinct type? In D Nullable!(int*) needs to be a different type, because the interface is different between a pointer and a Nullable. It could be normalized by free functions isNull(T)(T t), nullableValue(T)(..) etc. Isn't that what was done to arrays so they could support the range interface? But often you want to use something like Nullable(int*, null) or Nullable(int*, cast(int*)null) instead. Do you have an example? In what cases is the distinction between a null null int* and non-null null int* necessary? In the second case maybe it can be collapsed into a single Nullable, but such behavior needs to be documented. Ok. Bye, bearophile
Re: Low-Lock Singletons In D
On Friday, 24 May 2013 at 13:05:36 UTC, bearophile wrote: Max Samukha: Note that the Nullable is not phobos Nullable - the latter incurs unnecessary overhead for types that are already nullable. In Bugzilla I have suggested some improvements for Nullable, but in Phobos there is already an alternative Nullable that avoids that overhead: struct Nullable(T, T nullValue); Bye, bearophile The question is what should be the result of: Nullable(int*)? Nullable!(Nullable!T)? Forbidden (like in C#)? Aliased to the source type? A distinct type?
Re: Low-Lock Singletons In D
On Monday, 6 May 2013 at 17:58:19 UTC, Walter Bright wrote: On 5/6/2013 6:14 AM, Max Samukha wrote: FWIW, I played with a generalized form of this pattern long ago, something like (typing from memory): And, that's the classic double checked locking bug! D man is the bug! I simply failed to insert a line that flags the thread-local guard. Sorry for that. The Nullable thing was an impromptu to avoid ugly specializations I used for nullable and non-nullable types in my original implementation. Note that the Nullable is not phobos Nullable - the latter incurs unnecessary overhead for types that are already nullable. Maybe, the use of Nullable is an overkill and a __gshared boolean (redundant in case of a nullable type) would suffice. David mentioned the trick on this NG years ago. It is well known, understood and would be rarely needed if D could properly do eager initialization of global state. :P Anyway, I popped up mainly to point out that the pattern should not be limited to classes.
Re: Low-Lock Singletons In D
On Monday, 6 May 2013 at 02:35:33 UTC, dsimcha wrote:
On the advice of Walter and Andrei, I've written a blog article
about the low-lock Singleton pattern in D. This is a
previously obscure pattern that uses thread-local storage to
make Singletons both thread-safe and efficient and was
independently invented by at least me and Alexander Terekhov,
an IBM researcher. However, D's first-class treatment of
thread-local storage means the time has come to move it out of
obscurity and possibly make it the standard way to do
Singletons.
Article:
http://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/
Reddit:
http://www.reddit.com/r/programming/comments/1droaa/lowlock_singletons_in_d_the_singleton_pattern/
FWIW, I played with a generalized form of this pattern long ago,
something like (typing from memory):
template sharedGlobal(alias ctor, alias lock = globalLock)
{
@property sharedGlobal()
{
alias ReturnType!ctor T;
__gshared static Nullable!T t;
static bool instantiated;
if (!instantiated)
{
synchronized(lock)
{
if (t is null)
t = ctor();
}
}
return cast(T)t;
}
alias sharedGlobal!({ return new Blah(); }) blah;
It should have been part of QtD but that has never happened.
Re: DIP23 draft: Fixing properties redux
On Tuesday, 5 February 2013 at 18:33:36 UTC, Andrei Alexandrescu wrote: Walter and I reviewed the discussion and had a long talk. We are very seriously considering banning the use of & against a ref result from a function Please, no. ref T foo(); extern(C) void bar(T*); bar(&foo()); // how?
Re: @property - take it behind the woodshed and shoot it?
On Monday, 28 January 2013 at 21:54:21 UTC, Michael wrote: On Monday, 28 January 2013 at 21:03:04 UTC, Max Samukha wrote: Let's face it: there are *no* objective criteria for determining whether a mutator should be a function or property setter. Yes, but also it's should be a lightweight action (main idea). I think we need something more measurable than lightweight-ness to justify a language feature. As proposal: http://forum.dlang.org/post/ydcjggoibjmuuoobg...@forum.dlang.org And C# Property notes http://msdn.microsoft.com/en-us/library/w86s7x04.aspx http://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx and quote At all, it looks like C# style in D Way. --no-parenthesis for current behaviour for non-property functions.
Re: @property - take it behind the woodshed and shoot it?
On Monday, 28 January 2013 at 18:43:19 UTC, Andrei Alexandrescu
wrote:
On 1/28/13 1:04 PM, Dicebot wrote:
On Monday, 28 January 2013 at 17:52:45 UTC, TommiT wrote:
If you think my example of {start_time, end_time, duration}
represents
proper use of properties, then I don't see why you oppose
array.length. To me it seems like the same thing. Array has
some
length, and you can change it by changing its length
property. T
represents a certain time range, and you can change it by
changing any
of its three properties {start_time, end_time, duration} which
describe that time range.
T changes its inner encapsulated states. Period. It is no
different that
properties that calculate result on the fly, like range.empty
(which is
good property usage).
Array.length allocates. Takes from some global resources,
takes some
considerable time, calls some global allocating function.
For me it is a crucial difference that pushes symbol to the
world of
functions.
I guess you hate if people want their bigints to assign with a
= b.
Andrei
widget.height = 100 should be condemned, too - it changes the
state of the entire GUI system.
Let's face it: there are *no* objective criteria for determining
whether a mutator should be a function or property setter.
Re: Internal and external iteration, fibers
On Tuesday, 22 January 2013 at 05:51:16 UTC, Philippe Sigaud wrote: On Tue, Jan 22, 2013 at 2:55 AM, deadalnix wrote: On Monday, 21 January 2013 at 19:23:19 UTC, Jacob Carlborg wrote: I know people don't like it but I have to say, this seems it could be a job for AST macros. I was thinking the same thing, but don't wanted to bug people. Indeed, it is the perfect job for AST macro. I can concur now that you mentioned it xD Would any of you be so kind as to propose another definition for AST macros here ? http://wiki.dlang.org/Commonly-Used_Acronyms AST macros is CTFE done right :)
