Re: Phobo's migration
On Wednesday, 22 June 2016 at 16:44:25 UTC, Joerg Joergonson wrote: How bout Freezing Phobos, except for bugs and start migrating it to Phobos 2.0?. phobos is already 2.0. It has the same version as the compiler it's distributed with. For someone who has "so ambitious plans" for phobos you should at least know that ;) [...]
Re: Right after allocators: containers or database connectivity?
A container similar to folly's small_vector would be great to have ( https://github.com/facebook/folly/blob/master/folly/docs/small_vector.md) On 9 June 2015 at 18:11, Jonathan M Davis via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 9 June 2015 at 21:53:55 UTC, Andrei Alexandrescu wrote: Regarding projects that we discussed you are considering, I suggest we focus on putting std.container in good shape and opt for a redesign only if there are great benefits. Also, I think we should stay with libc-based I/O. Honestly, I think that std.container's API is a very good start. The main problems lie with ranges. We need to make sure that all of the range-based functions are consistent (e.g. accepting Take!R, TakeOne!R, TakeExactly!R, etc. where R is the range type for that container - we do that to some extent, but we're not consistent about it), and we need to add more functions that don't use ranges - in particular, remove functions which remove keys or values without having to use a range to do it. Honestly, while it's flexible, it's not exactly the finest hour for ranges when you have to do something like container.remove(container[].find(value).takeOne()); just to remove a value for the container. Most folks just want to do something like container.removeFirst(value); And containers are really the main place, I think, where iterators actually do better than ranges. So, while I definitely want the containers to continue to support ranges, I think that we should do a better job of having alternative functions which don't involve ranges if they don't need to for many of the basic cases. Then the simple cases won't have to use ranges just to do stuff like remove elements, and generic code and more complicated cases can use ranges as appropriate. But in general, while I do think that some polishing is needed for the std.container API, I also think that it's a very solid start. - Jonathan M Davis -- -=Miles Stoudenmire=- miles.stoudenm...@gmail.com emi...@pitp.ca http://itensor.org/miles/
Re: enums
In contrast to those two examples where immutable can be used at compile
time, what are some other cases where it is necessary to use enum instead
of immutable?
On 31 May 2014 09:33, Andrej Mitrovic via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
This has been asked so many times, is this info not on the website? We
should have an article on the site explaining this in depth. OT: Sorry for
top-quoting and over-quoting.
On Friday, May 30, 2014, monarch_dodra via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Friday, 30 May 2014 at 15:30:15 UTC, Russel Winder via
Digitalmars-d-learn wrote:
I think I have no idea what D enums are about.
Bearophile's example of some code in an email on another thread uses:
enum double p0 = 0.0045;
Now I would have written:
immutable double p0 = 0.0045;
or at the very worst:
const double p0 = 0.0045;
For me, enum means create an enumerated type. Thus enum double to
define a single value is just a contradiction.
Enlightenment required…
The keyword enum stems from the enum hack in C++, where you use:
enum {foo = 100}; //Or similar
As a way to declare a manifest constant known at compile time.
D simply hijacked the enum keyword to mean manifest constant that
is known at compile time.
Compared to an immutable instance:
* The immutable instance creates an actual reference-able object in your
binary. The enum will not exist outside of the compilation (think of it as
a higher order macro)
* immutable represents a value, which *may* be initialized at runtime.
In any case, more often than not (I have observed), the compiler will
refuse to use the immutable's value as compile-time known, and it won't be
useable as a template parameter, or static if constraint.
--
-=Miles Stoudenmire=-
miles.stoudenm...@gmail.com
emi...@pitp.ca
http://itensor.org/miles/
Re: A new blog article detailing the alternative function syntax
s/quiet easily/quite easily/g Nice article. I wish C++ had UFCS... On 8 August 2013 20:40, Jesse Phillips jesse.k.phillip...@gmail.com wrote: On Thursday, 8 August 2013 at 18:53:47 UTC, Gary Willoughby wrote: I've just finished a new blog article on the subject of alternative function syntax in D. I guess this is pretty straightforward stuff to all the people here but was a major source of confusion to me (and others?) when first learning D. I personally think this is more confusing than many people think. Hopefully this will quickly arm a developer with knowledge to be able to read and understand most D code. Let me know if i've missed anything important. http://nomad.so/2013/08/**alternative-function-syntax-**in-d/http://nomad.so/2013/08/alternative-function-syntax-in-d/ I'll post to reddit in the morning. The second non-member function example is part of the -property controversy. foo = 123; // called as foo(123) Not sure if you'd want that mentioned. -- -=Miles Stoudenmire=- miles.stoudenm...@gmail.com estou...@uci.edu http://itensor.org/miles/
Re: T-shirt design
I want to second Steven's suggestion that the code have a template instantiation in it. auto event = menlo!park(2013); ? On Friday, 15 March 2013 at 21:13:42 UTC, Iain Buclaw wrote: On 15 March 2013 21:07, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote: On 3/15/13 2:37 PM, kraybit wrote: On 3/15/13 19:09 , Andrei Alexandrescu wrote: Would love if the moon would be actually a small Earth, is that possible? Andrei Two versions with the 'ol home planet in them coming up! One small Earth instead of the second moon (would need more work for fair comparison though), and one tiny Earth to the left of the big D, easter-egg-style. Tshirt mockup (tiny Earth, 2 moons) https://www.dropbox.com/s/**a42l6r8kobqtwb1/tshirt_3a.pnghttps://www.dropbox.com/s/a42l6r8kobqtwb1/tshirt_3a.png Love this, and the tiny Earth is a good easter egg. Should I send it to the Facebook folks for production? Andrei Can't wait to get one. :-)
Re: Should D1 only bugs be closed?
On Sunday, 10 February 2013 at 03:20:26 UTC, David Nadlinger wrote: That post is over a year old, and the point was precisely that recent development activity seemed to contradict this statement. The D Progamming Language book discusses this decision as well.
Re: Focus
Here is a helpful discussion on stack overflow about whether friend in C++ breaks encapsulation: http://stackoverflow.com/questions/1093618/how-does-the-friend-keyword-class-function-break-encapsulation-in-c Also an article on encapsulation by Scott Meyers: http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 Basically I think the consensus is that encapsulation != everything is private. Also I like Meyer's point that encapsulation is a means, not an end. On 18 January 2013 20:11, Craig Dillabaugh cdill...@cg.scs.carleton.ca wrote: snip Anyway, just wanted to say that this thread got off topic in an awful hurry. It sort of funny that the thread started off with a complaint about Walters lack of focus and quickly got off topic. Maybe lack of focus is a common attribute of people interested in D. I suggested that D be renamed the ADD language. -- -=Miles Stoudenmire=- miles.stoudenm...@gmail.com estou...@uci.edu http://itensor.org/miles/
Re: Website message overhaul
Would it be possible to add little plus signs to the See example links? I was surprised when I clicked one because I expected it to open a new page, not pop open a block of code below. On 15 November 2011 09:59, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 11/15/11 8:13 AM, Jeff Nowakowski wrote: On 11/15/2011 09:31 AM, Andrei Alexandrescu wrote: It's true that I generally post negative critique, and that's because I tend to post when things get my dander up enough. That doesn't mean the message is frivolous or wrong. If I wanted to snipe like that I'd be posting here several times a week on multiple topics. I don't. Would be great to also post when you feel you could help with something. Andrei -- -=Miles Stoudenmire=- miles.stoudenm...@gmail.com
Re: Exponential operator
Don wrote: You didn't respond to my assertion: even if you _could_ do it, why would you want to? ** sucks as an exponential operator. I dispute the contention that ** is a natural choice. It comes from the same language that brought you IF X .NE. 2 There are too many languages that support ** as an exponentiation operator, that is the reason ** is a likely candidate. Your reasoning seemed to be: - Fortran is bad; - Fortran had ** as its exponentiation operator; - So, ** is bad as an exponentiation operator. I don't care for ** or .NE., really. I don't like * as a multiplication operator, in fact. I'd rather have × as multiplication, ↑ as exponentiation, ∧ as logical and, ∨ as logical or, ¬ as a logical not, = as equality, ≠ as inequality and ← as assignment. I don't know why, but every time I say this, it brings all sorts of controversies and euphoric reactions.
Re: Exponential operator
Lars T. Kyllingstad wrote: Neither of the natural candidates, a^b and a**b, are an option, as they are, respectively, already taken and ambiguous. I think that a ** b can be used, is not ambiguous except for the tokenizer of the language. It is the same difference you have with: a ++ b - identifier 'a', unary operator '++', identifier 'b' (not parseable) a + + b - identifier 'a', binary operator '+', unary operator '+', identifier 'b' (parseable) I don't know anyone who writes ** to mean multiplication and dereference, except when obfuscating code. People usually prefer adding a whitespace between both operators, for obvious readability purposes. I think it is perfectly reasonable to deprecate current usage of '**' for the next release, and a few releases later, make '**' a new operator. I doubt anyone would notice. Other examples: a-- - b a - --b a b a b
Re: bigfloat
superdan wrote: the fuckin' gov't debt. Funny, but as a side note, currency calculation shouldn't be done with floats, but with *integers* (or fixed-precision numbers, that is ultimately equivalent to integers that represent some minimal fraction of the currency unit, usually cents).
Re: Allowing relative file imports
Jarrett Billingsley wrote: One, you do not use Javascript as a server-side scripting language. Why not? Server-side JavaScript exists since 1996. http://www.aptana.com/jaxer/ http://www.modjs.org/
Re: Is implicit string literal concatenation a good thing?
Frank Benoit wrote: Find the bug: static string[] KEYWORDS = [ abstract, alias, align, asm, Out of curiosity, are you trying to create a D parser? Because private:, protected:, public: and ~this are not keywords.
Re: Properties
Bill Baxter wrote:
Not sure what you mean by that. It's just foo vs foo in most cases.
...Except for some cases like where you're trying to return a delegate.
It is more tied with the intuitive use of symbols. 'foo' is a function,
add a '' before and you take its address, add a '(...)' after and you
make a call and take its return value. The implicit call syntax without
parentheses breaks this intuitive use.
In fact, if you follow the principle of orthogonality, instead of
calling the function without parameters, it would be much more sensible
to have 'foo' return the function address, and deprecate the address
operator. Then you could have functions and function/delegate pointers
with similar semantics (principle of least surprise).
-
int func1() { return 1; }
auto a = func1; // 'a' is a pointer to func1
auto b = func1;// ERROR, or deprecated way of above
auto c = func1(); // calls func1 and returns int 1
int function() func2 = func1;
auto d = func2; // 'd' is a pointer to func1
auto e = func2;// 'e' is a ptr to ptr to func
auto f = func2(); // calls func1 and returns int 1
-
Note that this way you have less surprises. Both func1 (the real
function) and func2 (pointer to function) behave in similar ways. In
current D, 'a' will be different than 'd', while 'c' will be equal to 'f'.
The reasoning for deprecating func1 is that func1 is not a variable,
neither it is an lvalue.
But now it is quite already too late to fix this, unless we go through a
long period of deprecating the current behavior, until we can implement
the new sane one.
He may want to retain the ability to pass it as a delegate to some
other function too. If you make properties distinct from functions,
then I don't think this can be allowed.
Yes, they are basically two distinct, mutually exclusive, compromises. A
property is syntax sugar to a collection of delegates (all of them share
the same scope). Properties are views that aim to behave as much as
possible as variables. Optimally, you must ignore completely if a given
symbol is a property or a variable. So, it makes little sense to pass a
property as a delegate to a function.
But it is still possible, and the solution actually keeps the
fundamental property that variables and properties should be almost
indistinguishable:
--
int m_prop;
property int prop {
get() { return m_prop }
set(int value) { m_prop = value; }
}
// lets say that func expects a setter
func1( (int value){ prop = value; } );
// and func2 expects a getter
func2( (){ return prop; } );
--
See? You passed delegates to the functions, and you kept the compromise
that the code doesn't make distinction between properties and variables.
The following code (taking the property out) is still valid:
--
int prop;
func1( (int value){ prop = value; } );
func2( (){ return prop; } );
--
So you'd need to have the
property and a function that wraps the property.
Exactly, or, instead of a function, an inline delegate is enough. As
shown above, you win because then the code becomes insensitive to
whether prop is a property or a variable.
Then you've just made more work for yourself.
This is such a corner case that I think that using inline delegates is a
good enough solution.
Hmm, maybe properties should be
allowed to be turned into delegates.
The compiler could provide a syntax for that. Like I said, a property is
just a collection of delegates under a single identifier. For example,
tentative syntax:
--
property int prop { ... }
auto setter = property(prop).set;
// setter has type 'void delegate(int)'
auto getter = property(prop).get;
// getter has type 'int delegate()'
--
But I think this is a secondary feature (if we keep demanding solutions
for the corner cases, we will never have the solution for the biggest
problem). I could live fine without this feature.
Re: Properties
Andrei Alexandrescu wrote: Walter and I see eye to eye that a possible solution would be to only allow the a = b syntax as an alternative for a(b) only if there's also a function a(). All of the above can be fixed within that framework. That would only patch a single consequence of the much bigger core problem that is the current property syntax. Not to say that, although rare, it is perfectly possible to have write-only properties. I once wrote a microcontroller emulator that had a few write-only registers, serial port output, for example.
Re: Properties
Daniel Keep wrote:
Yes, property syntax can simplify some cases, but this isn't one of them.
One good distinction properties and normal functions ought to make is
that functions should never be called without (), and properties should
never have () unless it has a function type.
Current syntax allows crazy things like:
--
exit = 1; // it is not an assignment
x = toString = getenv = PATH; // creepy, but valid D
if (fork == 1) // not comparing the value of a variable
--
Also, currently, in D, if you have a property of a delegate type, you
will have a mess.
--
int func2() { return 42; }
/* this is a property */
int function() prop() {
return func2;
}
void main() {
auto x = prop; // ok, x is a func ptr
auto y = prop();// unexpected: y is not int :-(
static assert (is(typeof(y) == int));
}
--
With properties, you forbid the above syntaxes.
So, what is better about properties is not shorter syntax, but giving
proper semantics for a given symbol.
Also, properties can be part of interfaces, enforcing derived classes to
implement them in a given way.
Re: Properties
dsimcha wrote: I for one think that code is often more readable without the annoying empty parentheses around functions that don't take any arguments. It introduces ambiguities, and unexpected behavior, as I exemplified in the previous message. Parentheses (when following an identifier) has a precise meaning of calling the named function. That is something most modern procedural languages do, it is something programmers are used to. I see no advantage at giving the privilege to no-argument functions of being called without parentheses, while at the same time you lose the ability to distinguish between _calling_ the function from _referring_ to it. This is especially true for member functions of classes and structs, Aren't these member functions good candidates to be made into real properties? If you want or need to use an identifier without parentheses, you have the option of making it into a property. Very simple. even moreso when chaining them such as foo.bar.baz vs. foo().bar().baz(). From your example, it appears that the purpose of foo and bar, and perhaps baz are to return instances, so they could just be turned into properties, and have the exact syntax you expect. So? The spec is not there to prevent people from doing stupid things (making it harder to do stupid things *by accident* is a reasonable goal, but we're all consenting adults here). Anyone who would actually do stuff like this on purpose in their code is an idiot and deserves what they get. One could just as easily do some pretty stupid things with operator overloading, casts, templates, you name it. Just because stupid things *can* be done with a feature doesn't mean the feature should be removed. You seem to be missing the point. In fact, you ignored the most important example in my previous message that shows how the current D's property syntax can be damaging. Also, your reasoning fails to take into account the difference between _allowing_ a certain syntax, and _incentivating_ bad usage.
Re: Properties
Nick Sabalausky wrote:
Well, like I said, *If* we were to get overload-on-return-value. Not that
I'm itching for it or anything. I've just seen the idea discussed before and
if it hypothetically were to happen, then the above could work as a getter
equivilent.
Ok. But I think such feature would create a mess. For example:
intfunc1() { ... }
char[] func1() { ... }
void func2(int x) { ... }
void func2(char[] x) { ... }
func2(func1()); // what is the expected behavior?
When you are inferring types, you need somewhere to anchor the compiler
decision, either on the sender or on the receiver side.
Re: Properties
Nick Sabalausky wrote:
This proposal doesn't prevent any of that. Suppose our syntax was like in
the example above. I would still be able to do something like this:
---
protected int _var;
public property char[] var
{
// char[] internalValue is still defined,
// but gets optimized away since it's never used.
get { return ToString(_var); }
set { _var = ToInt($); }
}
---
The problem I see with this is that it complicates the implementation of
properties. Properties are just collections of delegates, perhaps even
optimized to contain only a single frame pointer for multiple function
pointers. Properties may appear in contexts where you can't have member
variables (e.g., interfaces).
---
class Foo
{
public property int myProp
{
get { return internalValue; }
set { internalValue = $; }
}
public bar()
{
Stdout.formatln({}, myProp.internalValue);
}
}
---
Won't work, not like that. For the compiler, that is difficult to
distinguish from calling the getter for myProp (that returns an int),
and trying to access a member variable called internalValue from that
int instance.
The compiler could provide some syntax to disambiguate property's
members from it's value's members. Perhaps:
property(myProp).internalValue;
In this case, property(...) tells the compiler to handle the argument as
the property itself, without calling the getter. But requiring that
syntax just sucks. I find it better to have the value in another variable.
Re: Properties
Nick Sabalausky wrote: A property setter is ALWAYS going to return nothing and Both the getter and the setter should return an rvalue. Properties exist so that they are interchangeable with real member variables. Something that is possible with member variables MUST also be possible with properties, in a transparent way for any code outside the class. For example: button.width = button.height = 50; // makes a square button Optimally, this should expand to either: button._set_width(button._set_height(50)); or button._set_height(50); button._set_width(button._get_height()); From the compiler point-of-view, the first is easier to implement. take in exactly one argument, of the same type as the property, and that value will ALWAYS represent the intended new value. Also not true. It is fine to have method polymorphism for the setter. You may want to define property set(int value), set(Bigint value) and set(float value), all with different semantics.
Re: Disallowing ?:?: syntax
Nick Sabalausky wrote: This makes my highly DRY-oriented mind think: While ?: is an expression-based counterpart to the statement-based if...else, maybe we could use a similar expression-based counterpart to switch? (I think I've seen such a thing in hardware description languages) I think I have seen that using a mixture of recursive templates and lazy evaluation. But sure, that would be a nice addition to support a relatively common use-case. Two things I miss are the ?: GNU C extension ( a ?: b expands to a ? a : b , except that a is evaluated only once) or the ?? C# construct (similar idea, but only tests for null reference).
Re: Disallowing ?:?: syntax
bearophile wrote: My little proposal for D is to turn the following into a syntax error, to avoid possile programmer mistakes (so the programmer must put parentheses here to make it compile): x ? y : a ? b : c The ternary operator is not ambiguous, I see no need for making it an error. I have used such constructs very often, with no problem: writefln(Printer is %s., status == OFFLINE ? offline : status == ONLINE ? online : status == CHECK? out of paper : status == ONLINE_CHECK ? on fire : unknown status); That would become a real mess of parenthesis.
Re: 128 bit signed and unsigned integer types
Walter Bright wrote: You know, the unimplemented 128 bit integer types. Does anyone have a use for these? In distributed systems, *a lot*. 1. In network programming, IPv6 addresses are becoming very common (nobody should ever think about writing a network-enabled application without native IPv6 support nowadays). IPv6 addresses are 128-bit. No arithmetic is needed, just copy, comparison and bitwise, masking and bitshift operations. 2. Also, UUIDs[1] and other similar universal identification schemes are very common, we use them all the time in distributed systems. They are 128-bit numbers, only copy, comparison and bitwise operations are needed. 3. In cryptography, also very common in distributed systems, it is common to have symmetric ciphers with key sizes of 128 and 256-bits. We currently have to break the cypher blocks in peaces and move a lot of the complexity up to the algorithm level in order to process such data in 32 or 64-bit registers and variables. It would be great if cryptographers could trust compilers to do this in the lower level (properly using SSE registers and so). In all these cases, bigints are completely inadequate. I currently have to use (for the first two cases) a struct with operators implemented in asm (with different versions for x86 and x64) for efficient manipulation of these numbers. All this in C and C++. [1] http://en.wikipedia.org/wiki/Universally_Unique_Identifier
