date:20130529

With regard to the last point in the talk where Walter was 
suggesting not calling finalizers on objects whose code has been 
unloaded - would it not make more sense to simply call all the 
finalizers before unloading the library?


If the finalizer is not called you will potentially get resource 
leaks - although there's no guarantee currently that it will be 
called, isn't there the assumption that if it's not called the 
object still exists, even if it's not referenced anywhere? ie. 
you still have some guarantee that if you keep allocating objects 
and then unreferencing them that the number of unfinalized 
objects will never exceed some large but fixed value.

Re: DConf 2013 Day 2 Talk 2: Shared Libraries in D by Martin Nowak

2013-05-29 Thread Andrei Alexandrescu


On 5/29/13 10:05 PM, Meta wrote:

On Wednesday, 29 May 2013 at 14:44:38 UTC, Andrei Alexandrescu wrote:

http://www.reddit.com/r/programming/comments/1f9qq3/dconf_2013_day_2_talk_2_shared_libraries_in_d_by/


Apologies for the delay. Enjoy and vote up!


Andrei


The first couple talks were posted to Hacker News as well. Have you
stopped posting these there now?


Walter used to do that. I'll do it from now on.

https://news.ycombinator.com/item?id=5790649


Andrei

Re: DConf 2013 Day 2 Talk 2: Shared Libraries in D by Martin Nowak

2013-05-29 Thread Steven Schveighoffer


On Wed, 29 May 2013 22:12:54 -0400, Diggory digg...@googlemail.com wrote:

With regard to the last point in the talk where Walter was suggesting  
not calling finalizers on objects whose code has been unloaded - would  
it not make more sense to simply call all the finalizers before  
unloading the library?


In fact, I think in discussions after the talk (not recorded on video), we  
came to the same conclusion.  If you are unloading the library and have  
any pointers to classes from that library, that is a programming error.   
So it should be safe to destroy all known objects from that library.


-Steve

Re: DConf 2013 Day 2 Talk 2: Shared Libraries in D by Martin Nowak

On Thursday, 30 May 2013 at 04:00:18 UTC, Steven Schveighoffer 
wrote:
On Wed, 29 May 2013 22:12:54 -0400, Diggory 
digg...@googlemail.com wrote:


With regard to the last point in the talk where Walter was 
suggesting not calling finalizers on objects whose code has 
been unloaded - would it not make more sense to simply call 
all the finalizers before unloading the library?


In fact, I think in discussions after the talk (not recorded on 
video), we came to the same conclusion.  If you are unloading 
the library and have any pointers to classes from that library, 
that is a programming error.  So it should be safe to destroy 
all known objects from that library.


-Steve


Ah, good to know :)

Re: [article] Language Design Deal Breakers


On Wednesday, 29 May 2013 at 05:35:14 UTC, Walter Bright wrote:

On 5/28/2013 9:55 PM, Diggory wrote:
As a last resort there should be a runtime check available 
such as

assertNotNull(T) which does the conversion.


The idea is to put the check on assignments to NotNull, not on 
usage of it.


I know, that's what my suggestion was for.

assertNotNull(T) would return a NotNull!T given a T (probably 
should have explained that)


The reason for that, as opposed to checking in the assignment 
operator is that it's possible to assign to a variable without 
knowing that it's supposed to be NotNull:


someVar.someProperty = normalPtr; // Won't detect this at compile 
time


If assertNotNull(T) is needed then it's obvious:

someVar.someProperty = assertNotNull(normalPtr)

And without it the compiler can issue an error message.

If there's no compile time detection of problems then there's no 
point using NotNull, you're just replacing null pointer 
exceptions by a different exception.

Re: Inability to dup/~ for const arrays of class objects

2013-05-29 Thread Ali Çehreli


On 05/28/2013 07:24 PM, Jonathan M Davis wrote:

 On Tuesday, May 28, 2013 18:19:49 Ali Çehreli wrote:
 I remember the discussions on that topic and various syntax proposals
 but I don't remember why class variable assignment syntax would not 
work:


 The problem is that the type system does not differentiate between a 
class
 object and a reference to a class object. The type refers explicitly 
to the

 reference, not the object. It doesn't have the concept of a class object
 separate from its reference

However, most of the operations on a class reference are relayed to the 
object:


  auto r = new C();
  r.foo();// relayed to the object
  r.bar = 42; // relayed to the object
  writeln(r); // relayed to the object
  // ...  // etc.

With exception of assignment, which stays with the reference:

  r = new C();// on the reference

How about the following two rules, which do not require any syntax 
change. Let's make it so that there are two kinds of type checks on a 
class reference:


1) For operations that involve the object, perform the type check as it 
is today.


2) The assignment operation is type-checked specially:

  const: Allow the assignment for any type on the right-hand side)

  immutable: Allow the assignment for only immutable on the right-hand side

  mutable: Allow the assignment for only mutable on the right-hand side

Of course this throws out the current behavior of non-mutable references 
being non-rebindable, but I think non-rebindable references are 
overrated. Even in C and C++, most of the time it is the data that is 
const. For example, nobody takes 'const char * const' parameters. Yes, 
it is helpful in theory, but programmers simply define the parameter as 
'const char *'. (Or 'char const *' if they are more purist. :) )


It seems simple enough but perhaps it is too difficult to implement at 
this point. Only Kenji can tell! ;)


Ali

Re: Inability to dup/~ for const arrays of class objects

2013-05-29 Thread Jonathan M Davis

On Tuesday, May 28, 2013 22:58:39 Ali Çehreli wrote:
 On 05/28/2013 07:24 PM, Jonathan M Davis wrote:
   On Tuesday, May 28, 2013 18:19:49 Ali Çehreli wrote:
   I remember the discussions on that topic and various syntax proposals
   but I don't remember why class variable assignment syntax would not
 
 work:
   The problem is that the type system does not differentiate between a
 
 class
 
   object and a reference to a class object. The type refers explicitly
 
 to the
 
   reference, not the object. It doesn't have the concept of a class object
   separate from its reference
 
 However, most of the operations on a class reference are relayed to the
 object:
 
auto r = new C();
r.foo();// relayed to the object
r.bar = 42; // relayed to the object
writeln(r); // relayed to the object
// ...  // etc.
 
 With exception of assignment, which stays with the reference:
 
r = new C();// on the reference
 
 How about the following two rules, which do not require any syntax
 change. Let's make it so that there are two kinds of type checks on a
 class reference:
 
 1) For operations that involve the object, perform the type check as it
 is today.
 
 2) The assignment operation is type-checked specially:
 
const: Allow the assignment for any type on the right-hand side)
 
immutable: Allow the assignment for only immutable on the right-hand side
 
mutable: Allow the assignment for only mutable on the right-hand side
 
 Of course this throws out the current behavior of non-mutable references
 being non-rebindable, but I think non-rebindable references are
 overrated. Even in C and C++, most of the time it is the data that is
 const. For example, nobody takes 'const char * const' parameters. Yes,
 it is helpful in theory, but programmers simply define the parameter as
 'const char *'. (Or 'char const *' if they are more purist. :) )
 
 It seems simple enough but perhaps it is too difficult to implement at
 this point. Only Kenji can tell! ;)

Having const references or pointers is occasionally useful, but we wouldn't 
lose much IMHO if we lost them. Java got it backwards in that that's the 
_only_ kind of const that it has (via final). However, I don't know how 
feasible your suggestion is. Remember that there isn't really any difference 
between the reference and the object in the type system. When you mark a 
function as const, it's the this reference which is const. So, when you have a 
const C that you're operating on, it's the reference itself which is then the 
this reference and is passed around as const. As far as the type system is 
concerned, there's nothing else to _be_ const. So, you're asking for it to be 
treated as const as far as function calls go but treated as mutable otherwise, 
which goes against how const works. You're asking for a half-constness of 
sorts.

To make matters worse, what happens when you have a const object which has a 
reference as a member variable? e.g.

class C
{
class D d;
}

const C c;

Because of the transitivity of const, d must be fully const, and yet with your 
suggestion, it isn't. Or if it is, we now have a situation where the constness 
of a reference depends on its context, and the compiler must keep track of its 
context in addition to its type in order to determine whether it's fully const 
or just half const.

So, while at first glance, I think that your suggestion makes sense 
conceptually, I think that it's going to fall apart when we get into the 
details.

I confess that for the most part, I've just given up and resigned myself to 
using Rebindable.

- Jonathan M Davis

Re: Why UTF-8/16 character encodings?


On Wednesday, 29 May 2013 at 01:29:07 UTC, Diggory wrote:

On Tuesday, 28 May 2013 at 23:33:47 UTC, Peter Williams wrote:

On 28/05/13 19:12, Jacob Carlborg wrote:

On 2013-05-28 08:00, Manu wrote:


Is there anywhere other than America that doesn't?


Canada, Jamaica, other countries in that region?



Last time I looked Canada was in America (which is a continent 
not a country). :-)


Peter


America isn't a continent, North America is a continent, and 
Canada is in North America :P


Well, that point of view really depends from which continent 
you're from:

http://en.wikipedia.org/wiki/Continents#Number_of_continents

There is no internationally agreed on scheme. I for one, have 
always been taught that there is only America, and that the 
terms North America and South America where only meant to 
denote regions within said continent.

Re: Canonical/Idiomatic in memory files

2013-05-29 Thread Russel Winder

On Tue, 2013-05-28 at 22:33 -0700, Walter Bright wrote:
[…]
 Coincidentally, I wrote a wc program a year ago:

I note the one on the D web site could do with being made more
idiomatic. cf. http://dlang.org/wc.html

 -
 import std.stdio, std.file, std.string, std.array, std.algorithm, 
 std.typecons;
 import lazysplit;

As far as I know currently (which may mean I am very wrong), D imports
import all symbols defined in the module into the current name space.
This is like star imports in Python and Java which are now seen as not
the right thing to do. Python's default is to import the namespace not
the symbols in it and many believe this is the right thing to do.

 alias Tuple!(int, lines, int, words, int, chars) Lwc;

I used an int[3] for this, but I like the labelled tuple. Is this really
just a three item dictionary though. Might a dictionary be a better
structure for this?

 void main(string[] args) {
  writeln(   lines   words   bytes file);
 
  auto total = args[1 .. args.length].wctotal();
 
  if (args.length  2)
  writefln(--\n%8s%8s%8s total,
  total[0..3]);
 }

To emulate /usr/bin/wc, I dispensed with the - sequence. Less code ;-)

Is there an idiom of when to use 1..args.length and when to use 1..$ ?

 auto wctotal(R)(R args) {
  Lwc total;
  foreach (arg; args) {
  auto t = arg.File().byLine(KeepTerminator.yes).wc();
 
  writefln(%8s%8s%8s %s, t[0..3], arg);
 
  foreach(i, v; t)
  total[i] += v;
  }
  return total;
 }

Why a template? R is always string? The above does not cope with a
parameter being - to indicate use the stdin.

 auto wc(R)(R r) {
  Lwc t;
  foreach (line; r) {
  t.lines += 1;
  t.words += line.lazySplit().count();
  t.chars += line.length;
  }
  return t;
 }

The body of this function looks almost, but not quite, exactly like
mine :-)

 Just replace arg.File().byLine(KeepTerminator.yes) with a string filled 
 with 
 your mocked data.

No that is not acceptable, the code under test must remain unchanged in
order to be tested.

I have been having trouble with UFCS: x.f() has not been compiling I
have had to use f(x). There must be a reason why rdmd and ldc have not
allowed me to use whichever of the forms I want, I will have to
investigate further to create a smaller exemplar of the issue.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: D on next-gen consoles and for game development

On Wednesday, 29 May 2013 at 00:40:16 UTC, Manu wrote:

On 29 May 2013 03:27, Paulo Pinto pj...@progtools.org wrote:

Am 28.05.2013 15:33, schrieb Steven Schveighoffer:

On Sat, 25 May 2013 01:52:10 -0400, Manu
turkey...@gmail.com wrote:

What does ObjC do? It seems to work okay on embedded hardware

(although not
particularly memory-constrained hardware).
Didn't ObjC recently reject GC in favour of refcounting?

Having used ObjC for the last year or so working on iOS, it
is a very

nice memory management model.

Essentially, all objects (and only objects) are ref-counted
automatically by the compiler. In code, whenever you assign
or pass a
pointer to an object, the compiler automatically inserts
retains and

releases extremely conservatively.

Then, the optimizer comes along and factors out extra retains
and

releases, if it can prove they are necessary.

What I really like about this is, unlike a library-based
solution where
every assignment to a 'smart pointer' incurs a
release/retain, the
compiler knows what this means and will factor them out,
removing almost
all of them. It's as if you inserted the retains and
releases in the

most optimized way possible, and it's all for free.

Also, I believe the compiler is then free to reorder retains
and

releases since it understands how they work. Of course, a
retain/release is an atomic operation, and requires memory
barriers, so

the CPU/cache cannot reorder, but the compiler still can.
...

I imagine Microsoft also does a similar thing with their
C++/CX language

extensions (WinRT handles).

Yeah certainly. It's ref counted, not garbage collected. And
Android's V8
uses a
generationalhttp://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generational_GC_.28ephemeral_GC.29

incrementalhttp://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Stop-the-world_vs._incremental_vs._concurrent

collector...
That'd be nice!
ObjC and WinRT are both used successfully on embedded hardware,
I'm really

wondering if this is the way to go for embedded in D.
V8 uses an incremental collector (somehow?), which I've been
saying is
basically mandatory for embedded/realtime use. Apparently
Google agree.
Clearly others have already had this quarrel, their resolutions
are worth

consideration.

Implementing a ref-counted GC would probably be much simpler
than V8's
mythical incremental collector that probably relies on Java
restrictions to

operate?

Actually what I was implying was the cleverness of the compiler
to remove unnecessary increment/decrement operations via
dataflows, similar to what Clang does.

Otherwise you pay too much for performance impact specially if
multiple threads access the same objects. An incremental real
time GC wins hands down in such scenarios.

Google IO is always a nice source of information on how V8 works,

https://developers.google.com/events/io/sessions/324431687
https://developers.google.com/events/io/sessions/324908972

--
Paulo

Re: [article] Language Design Deal Breakers

2013-05-29 Thread Sergei Nosov


On Wednesday, 29 May 2013 at 04:15:52 UTC, Walter Bright wrote:

On 5/28/2013 7:40 PM, Jesse Phillips wrote:

On Monday, 27 May 2013 at 07:53:05 UTC, Walter Bright wrote:
In D, right now (and especially with the beta) you can use 
the NotNull template.


Where is this NotNull template? If it was in Phobos I would 
expect

http://dlang.org/phobos/std_typecons.html


It's not in Phobos yet:

struct NotNull(T) {
T p;

alias p this;

this(T p) {
assert(p != null, pointer is null);
this.p = p;
}

@disable this();

NotNull opAssign(T p) {
assert(p != null, assigning null to NotNull);
this.p = p;
return this;
}
}


What would be the NotNull.init.p value then?

Re: D on next-gen consoles and for game development

On Wednesday, 29 May 2013 at 00:46:18 UTC, Steven Schveighoffer 
wrote:
On Tue, 28 May 2013 20:40:03 -0400, Manu turkey...@gmail.com 
wrote:



ObjC and WinRT are both used successfully on embedded 
hardware, I'm really

wondering if this is the way to go for embedded in D.
V8 uses an incremental collector (somehow?), which I've been 
saying is
basically mandatory for embedded/realtime use. Apparently 
Google agree.
Clearly others have already had this quarrel, their 
resolutions are worth

consideration.


An interesting thing to note, Apple tried garbage collection 
with Obj-C, but only on MacOS, and it's now been deprecated 
since automatic reference counting was introduced [1].  It 
never was on iOS.


So that is a telling omission I think.

-Steve

[1] https://en.wikipedia.org/wiki/Objective-C#Garbage_collection


The main reason was that the GC never worked properly given the C 
underpinnings of Objective-C.


Too many libraries failed to work properly with GC enabled, plus 
you needed to fill your code with GC friendly annotations.


So I imagine Apple tried to find a compromises that would work 
better in a language with C safety.


Even that is only supported at the Objective-C language level and 
it requires both compiler support and that objects inherit from 
NSObject as top most class, as far as I am aware.


Anyway it is way better than pure manual memory management.

--
Paulo

Re: Long symbol names (Was: demangle doesn't work with...)

2013-05-29 Thread Johannes Pfau

Am Tue, 28 May 2013 18:26:08 -0400
schrieb Steven Schveighoffer schvei...@yahoo.com:

 On Tue, 28 May 2013 17:13:59 -0400, David Nadlinger
 s...@klickverbot.at wrote:
 
  On Tuesday, 28 May 2013 at 19:01:00 UTC, Steven Schveighoffer wrote:
  Nothing is breakage before shared library support is ready.  And
  it's almost ready...
 
  This comment makes me slightly nervous, as I think even then, we  
  shouldn't be too quick to commit to ABI stability. Quite on the  
  contrary, we need to make sure to aggressively tell users that
  they can't expect two pieces D code that were not compiled with the
  exact same compiler version to interoperate.
 
 Like it or not, dynamic library support means we need to pay more  
 attention to ABI breakage.  People will complain about what largely
 is not really a problem (since code is statically compiled, you
 essentially build it every time anyway).

We only have to do the library versioning right. If we increase the
major version with every release we can break the ABI as much as we
want. Older applications the will always use the old shared libraries,
newer application the new ones. This means you'll have 3-4 copies of
phobos/druntime on your system, but I don't think that is an issue.

I agree with David that stabilizing the ABI is not a good idea right
now. We don't have a standard ABI, toString/toHash might need to be
removed which will break everything, we have some modules in phobos that
should be replaced ASAP (std.stream, std.xml)...

Re: D on next-gen consoles and for game development

2013-05-29 Thread Rainer Schuetze




On 29.05.2013 02:46, Steven Schveighoffer wrote:

On Tue, 28 May 2013 20:40:03 -0400, Manu turkey...@gmail.com wrote:



ObjC and WinRT are both used successfully on embedded hardware, I'm
really
wondering if this is the way to go for embedded in D.
V8 uses an incremental collector (somehow?), which I've been saying is
basically mandatory for embedded/realtime use. Apparently Google agree.
Clearly others have already had this quarrel, their resolutions are worth
consideration.


An interesting thing to note, Apple tried garbage collection with Obj-C,
but only on MacOS, and it's now been deprecated since automatic
reference counting was introduced [1].  It never was on iOS.

So that is a telling omission I think.

-Steve

[1] https://en.wikipedia.org/wiki/Objective-C#Garbage_collection


Please note that you have to deal with circular references manually in 
Objective-C, introducing two types of pointers, strong and weak. I don't 
think this is optimal. If you want to deal with circular references 
automatically you again need some other kind of other garbage collection 
running.


A problem with the naive approach of atomic reference counting a counter 
inside the object (as usually done in COM interfaces, I don't know how 
it is done in Objective-C) is that it is not thread-safe to modify a 
pointer without locking (or a CAS2 operation that you don't have on 
popular processors). You can avoid that using deferred reference 
counting (logging pointer changes to some thread local buffer), but that 
introduces back a garbage collection step with possibly massive 
destruction. This step might be done concurrently, but that adds another 
layer of complexity to finding circles.


Another issue might be that incrementing a reference of an object when 
taking an interior pointer (like you do when using slices) can be pretty 
expensive because you usually have to find the base of the object to 
access the counter.


I won't dismiss RC garbage collection as impossible, but doing it 
efficiently and concurrently is not so easy.

I may have found a bug.

2013-05-29 Thread Jeremy DeHaan


Hey guys,

I believe I found a bug with Associative Arrays, and I want to 
make a bug report, but I am not sure what severity to place this 
under, or perhaps I am doing something wrong.



Here is what happens: If a class has a static Associative Array 
member, calling remove in the destructor will cause a invalid 
memory operation error if it is during a GC cycle(or at least at 
the end of the program). If the object is manually destroyed I 
get no such error. Also, if the Associative Array isn't a static 
member of the class and instead is a module scope variable, the 
error doesn't appear anymore.


I made a minimal example to show what I mean.

module main;

import std.conv;
import std.stdio;

void main(string[] args)
{
   AssocArrayTest test1 = new AssocArrayTest();

   //destroy(test1);
}


class AssocArrayTest
{
private static string[uint] ClassNames;
private static uint ClassIDCounter = 0;

private uint ID;
this()
{
ID = ClassIDCounter++;
ClassNames[ID] = AssocArrayTest  ~ text(ID);
writeln(ClassNames[ID]);
}

~this()
{
ClassNames.remove(ID);
}
}


Thoughts?

Re: Canonical/Idiomatic in memory files

2013-05-29 Thread Walter Bright


On 5/29/2013 12:02 AM, Russel Winder wrote:

On Tue, 2013-05-28 at 22:33 -0700, Walter Bright wrote:
[…]

Coincidentally, I wrote a wc program a year ago:


I note the one on the D web site could do with being made more
idiomatic. cf. http://dlang.org/wc.html


Yup.



-
import std.stdio, std.file, std.string, std.array, std.algorithm, std.typecons;
import lazysplit;


As far as I know currently (which may mean I am very wrong), D imports
import all symbols defined in the module into the current name space.


This is incorrect. They are implemented as sort of second class citizens in 
the current name space. This means that any declaration in the current name 
space overrides any in the import name space. If the name is not found in the 
current name space, and is found in more than one import, an ambiguity error is 
generated.




This is like star imports in Python and Java which are now seen as not
the right thing to do. Python's default is to import the namespace not
the symbols in it and many believe this is the right thing to do.


D imports also allow cherry-picking of individual names out of it.


alias Tuple!(int, lines, int, words, int, chars) Lwc;


I used an int[3] for this, but I like the labelled tuple. Is this really
just a three item dictionary though. Might a dictionary be a better
structure for this?


It's equivalent to:
   struct Tuple { int lines; int words; int chars; }
which is much more efficient than a dictionary.



void main(string[] args) {
  writeln(   lines   words   bytes file);

  auto total = args[1 .. args.length].wctotal();

  if (args.length  2)
  writefln(--\n%8s%8s%8s total,
  total[0..3]);
}


To emulate /usr/bin/wc, I dispensed with the - sequence. Less code ;-)

Is there an idiom of when to use 1..args.length and when to use 1..$ ?


Not really.



auto wctotal(R)(R args) {
  Lwc total;
  foreach (arg; args) {
  auto t = arg.File().byLine(KeepTerminator.yes).wc();

  writefln(%8s%8s%8s %s, t[0..3], arg);

  foreach(i, v; t)
  total[i] += v;
  }
  return total;
}


Why a template? R is always string?


It could be a string, wstring or a dstring.


The above does not cope with a
parameter being - to indicate use the stdin.


That's true. For stdin, you'd replace arg.File() with stdin.


auto wc(R)(R r) {
  Lwc t;
  foreach (line; r) {
  t.lines += 1;
  t.words += line.lazySplit().count();
  t.chars += line.length;
  }
  return t;
}


The body of this function looks almost, but not quite, exactly like
mine :-)


Just replace arg.File().byLine(KeepTerminator.yes) with a string filled with
your mocked data.


No that is not acceptable, the code under test must remain unchanged in
order to be tested.


You just need to get the component programming religion! and get away from using 
FILE*. There isn't anything fundamentally different from using a fake FILE* and 
using a template with a different InputRange. If that's still unacceptable, you 
can create an InputRange that is a class with virtual functions empty(), 
front(), and popFront(), then use derived classes for the File or string.

Re: [article] Language Design Deal Breakers

2013-05-29 Thread Walter Bright


On 5/29/2013 12:01 AM, Sergei Nosov wrote:

What would be the NotNull.init.p value then?


null, but use of it is disabled.

Re: D on next-gen consoles and for game development

On Wednesday, 29 May 2013 at 07:18:49 UTC, Rainer Schuetze wrote:

On 29.05.2013 02:46, Steven Schveighoffer wrote:
On Tue, 28 May 2013 20:40:03 -0400, Manu turkey...@gmail.com
wrote:

ObjC and WinRT are both used successfully on embedded
hardware, I'm

really
wondering if this is the way to go for embedded in D.
V8 uses an incremental collector (somehow?), which I've been
saying is
basically mandatory for embedded/realtime use. Apparently
Google agree.
Clearly others have already had this quarrel, their
resolutions are worth

consideration.

An interesting thing to note, Apple tried garbage collection
with Obj-C,

but only on MacOS, and it's now been deprecated since automatic
reference counting was introduced [1]. It never was on iOS.

So that is a telling omission I think.

-Steve

[1]
https://en.wikipedia.org/wiki/Objective-C#Garbage_collection

Please note that you have to deal with circular references
manually in Objective-C, introducing two types of pointers,
strong and weak. I don't think this is optimal. If you want to
deal with circular references automatically you again need some
other kind of other garbage collection running.

A problem with the naive approach of atomic reference counting
a counter inside the object (as usually done in COM interfaces,
I don't know how it is done in Objective-C) is that it is not
thread-safe to modify a pointer without locking (or a CAS2
operation that you don't have on popular processors). You can
avoid that using deferred reference counting (logging pointer
changes to some thread local buffer), but that introduces back
a garbage collection step with possibly massive destruction.
This step might be done concurrently, but that adds another
layer of complexity to finding circles.

Another issue might be that incrementing a reference of an
object when taking an interior pointer (like you do when using
slices) can be pretty expensive because you usually have to
find the base of the object to access the counter.

I won't dismiss RC garbage collection as impossible, but doing
it efficiently and concurrently is not so easy.

There is a nice document where it is described alongside all
restrictions,

https://developer.apple.com/library/mac/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226

Re: [article] Language Design Deal Breakers

2013-05-29 Thread Sergei Nosov


On Wednesday, 29 May 2013 at 07:35:43 UTC, Walter Bright wrote:

On 5/29/2013 12:01 AM, Sergei Nosov wrote:

What would be the NotNull.init.p value then?


null, but use of it is disabled.


So it breaks the ability to always make a default initialization 
of a struct. As I understand, this ability was kind of important. 
Is there any solution for this planned? And if no, do you 
provision any negative consequences?

Re: [article] Language Design Deal Breakers

2013-05-29 Thread Kenji Hara

2013/5/29 deadalnix deadal...@gmail.com

 No you are distording what I say. I said, and repeat it for the nth time,
 that the job compilerwise is the exact same.

 The code sample you present me is completely stupid. It simply show that
 you are confused between compiler implementation and language design.


I'm not tracking this long thread seriously.
But I want to know what is needed to implement NotNull!T in library.

Currently I recognize that it is necessary to fix compiler bugs around
@disable this(); at least.

@deadalnix, it seems to me that you argue that @disable this(); is
insufficient or useless to implement NotNull!T. If so, what is necessary to
do it? What is impossible thing by NotNullT?

Kenji Hara

Re: Canonical/Idiomatic in memory files


On Wednesday, 29 May 2013 at 07:32:53 UTC, Walter Bright wrote:

On 5/29/2013 12:02 AM, Russel Winder wrote:

On Tue, 2013-05-28 at 22:33 -0700, Walter Bright wrote:
[…]


You just need to get the component programming religion! and 
get away from using FILE*. There isn't anything fundamentally 
different from using a fake FILE* and using a template with a 
different InputRange. If that's still unacceptable, you can 
create an InputRange that is a class with virtual functions 
empty(), front(), and popFront(), then use derived classes for 
the File or string.


One of the things that made me a fan of OO, was when I understood
the types of file manipulations that were possible with the IO 
abstractions

available in most languages in comparison with was is possible in
a pure procedural world.

Sure iostreams, Java IO, .NET, Smalltalk might offer complex IO 
models, but
they are quite powerful for doing generic code over abstract data 
sources.


--
Paulo

Re: Need some opinions for a GUI editor

2013-05-29 Thread Denis Shelomovskij


29.05.2013 1:25, Flamaros пишет:

Hi,

I and a friend are developing a GUI library, and now our script engine
is ready to start a prototype (but far to be finished). We think to try
to create a GUI editor based on our library.
In this way, we'll see which features are need.

My concern is about how the editor have to works, we see two different
ways to do it :
1) Classic editor external to the user applications
  a) Good :
 - Lightweight (easy to deploy and test)
 - No need to modify application code
 - Stable due to isolation of application
 - Real-time edition but limited on one view (bad to preview menus
transitions)
  b) Bad :
 - Limited, plugins needed to extend editor components and his
knowledge of application (can't predict size of unknown application
specific items)

2) Integrated editor (launch with the user application in a second Window)
  a) Good :
 - Preview is the final result with real data
 - All application components accessible to the editor without
complex plugin system (in this way all editors components will be well
placed in the preview)
 - Full real-time edition (can preview menus transitions,...)
 - User can customize the editor
  b) Bad :
 - Intrusive in the application code
 - Force the user to port application on a desktop OS (Linux, Mac or
Windows), not friendly if he target only embedded devices (can be
bypassed with a remote system)
 - Less stable editor?

The second solution is commonly used in the video game industry, but is
the best choice for a larger usage?

What do you think about?


As for me, a GUI editor is completely unneeded. Currently I'm using GTK+ 
for my apps so I tried to use Glade a long time ago but finished 
manually writing all the code as it:


1. It is not complicated and not time-wasted at all.
2. It gives you more control on the application.
3. It saves you time (!) as you can use you own functions for common 
widgets creation/location patterns.


So if your library isn't that silly one where you have to manually 
specify widget location/size in parent don't waste your time on GUI editor.


--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: D on next-gen consoles and for game development

2013-05-29 Thread Manu

On 29 May 2013 17:18, Rainer Schuetze r.sagita...@gmx.de wrote:

On 29.05.2013 02:46, Steven Schveighoffer wrote:

On Tue, 28 May 2013 20:40:03 -0400, Manu turkey...@gmail.com wrote:

ObjC and WinRT are both used successfully on embedded hardware, I'm
really
wondering if this is the way to go for embedded in D.
V8 uses an incremental collector (somehow?), which I've been saying is
basically mandatory for embedded/realtime use. Apparently Google agree.
Clearly others have already had this quarrel, their resolutions are worth
consideration.

An interesting thing to note, Apple tried garbage collection with Obj-C,
but only on MacOS, and it's now been deprecated since automatic
reference counting was introduced [1]. It never was on iOS.

So that is a telling omission I think.

-Steve

[1]
https://en.wikipedia.org/wiki/**Objective-C#Garbage_collectionhttps://en.wikipedia.org/wiki/Objective-C#Garbage_collection

Please note that you have to deal with circular references manually in
Objective-C, introducing two types of pointers, strong and weak. I don't
think this is optimal. If you want to deal with circular references
automatically you again need some other kind of other garbage collection
running.

A problem with the naive approach of atomic reference counting a counter
inside the object (as usually done in COM interfaces, I don't know how it
is done in Objective-C) is that it is not thread-safe to modify a pointer
without locking (or a CAS2 operation that you don't have on popular
processors). You can avoid that using deferred reference counting (logging
pointer changes to some thread local buffer), but that introduces back a
garbage collection step with possibly massive destruction. This step might
be done concurrently, but that adds another layer of complexity to finding
circles.

Another issue might be that incrementing a reference of an object when
taking an interior pointer (like you do when using slices) can be pretty
expensive because you usually have to find the base of the object to access
the counter.

I won't dismiss RC garbage collection as impossible, but doing it
efficiently and concurrently is not so easy.

What do you think is easier, or perhaps even POSSIBLE in D?
A good RC approach, or a V8 quality concurrent+incremental GC?
I get the feeling either would be acceptable, but I still kinda like idea
of the determinism an RC collector offers.

I reckon this should probably be the next big ticket for D. The
long-standing shared library problems seem to be being addressed.

Re: any and all not in the doc-index

2013-05-29 Thread Stephan Schiffels

On Tuesday, 28 May 2013 at 22:31:13 UTC, Andrei Alexandrescu 
wrote:

On 5/28/13 6:19 PM, Stephan Schiffels wrote:

Hi,

is there a reason why any and all from std.algorithm are 
neither
linked in the function index nor in the cheat sheet list at 
the top of

std.algorithm's documentation page?
I am happy to change this and make a pull request, just 
weren't sure

whether it's on purpose.

Stephan


It's an omission, thanks for offering to make a pull request. 
Go for it!


Andrei


https://github.com/D-Programming-Language/phobos/pull/1320

Re: Need some opinions for a GUI editor


On Tuesday, 28 May 2013 at 21:25:05 UTC, Flamaros wrote:

Hi,

I and a friend are developing a GUI library, and now our script 
engine is ready to start a prototype (but far to be finished). 
We think to try to create a GUI editor based on our library.

In this way, we'll see which features are need.

My concern is about how the editor have to works, we see two 
different ways to do it :

1) Classic editor external to the user applications
 a) Good :
- Lightweight (easy to deploy and test)
- No need to modify application code
- Stable due to isolation of application
- Real-time edition but limited on one view (bad to preview 
menus transitions)

 b) Bad :
- Limited, plugins needed to extend editor components and 
his knowledge of application (can't predict size of unknown 
application specific items)


2) Integrated editor (launch with the user application in a 
second Window)

 a) Good :
- Preview is the final result with real data
- All application components accessible to the editor 
without complex plugin system (in this way all editors 
components will be well placed in the preview)

- Full real-time edition (can preview menus transitions,...)
- User can customize the editor
 b) Bad :
- Intrusive in the application code
- Force the user to port application on a desktop OS 
(Linux, Mac or Windows), not friendly if he target only 
embedded devices (can be bypassed with a remote system)

- Less stable editor?

The second solution is commonly used in the video game 
industry, but is the best choice for a larger usage?


What do you think about?


I always hold Delphi and C++ Builder as examples of a what a good 
UI editor should offer.


Currently Blend + VS are also another good examples for proper 
tooling for making good UIs.


--
Paulo

Re: DList and SList missing length property?

On Tuesday, 28 May 2013 at 22:29:02 UTC, Steven Schveighoffer 
wrote:
On Tue, 28 May 2013 17:11:06 -0400, monarch_dodra 
monarchdo...@gmail.com wrote:


A proper implementation should be able to track length anyway: 
provide 0(1) splice, and an amortized 0(1) length.


I've always wondered why the standard didn't decide to do 
*that*? I think *we* should provide that...


I'm not sure how that works, can you explain/have a link?

-Steve


Well, the basic idea is to give your list an m_size member. 
This starts at 0. Whenever the user does a push_back/pop_back or 
whatnot operation, the the m_size attribute gets correctly 
upgraded. At that point, calling size() simply returns m_size.


Now, once a splice operation gets called, the m_size gets reset 
to a magic value, to indicate that tracking of the size has been 
lost. Operations will seize upgrading m_size, until a call to 
size is made, at which point it will be re-calculated, once.


This, I think is the best solution, since it keeps people that 
use length in a safe position, while users of splice are also 
satisfied. Also, I *think* people who use splice tend to be more 
aware of the situation, and avoid calling length entirely. 
Implementation wise, it would mostly look like this:


template typename T
class list
{
size_t m_size = 0;

size_t push_back(T other)
{
//Normal Code

if ( m_size != std::numeric_limitssize_t::max() )
++m_size;
}
size_t splice(list::iterator first, list::iterator last)
{
//Normal Code

//Reset length
m_size == std::numeric_limitssize_t::max();
}

size_t size() const
{
if ( m_size == std::numeric_limitssize_t::max() )
//Re-evaluate m_size
m_size = std::distance( cbegin(), cend() );
return m_size;
}
};

Re: [article] Language Design Deal Breakers


On Wednesday, 29 May 2013 at 07:50:39 UTC, Kenji Hara wrote:
Currently I recognize that it is necessary to fix compiler bugs 
around

@disable this(); at least.

@deadalnix, it seems to me that you argue that @disable this(); 
is
insufficient or useless to implement NotNull!T. If so, what is 
necessary to

do it? What is impossible thing by NotNullT?



No I'm nto saying that this is impossible, I'm saying that 
@disable this() and non nullable pointer are the exact same 
feature.


To implement both, the compiler have to track initialization of 
the value and yell at you if it isn't done, or if the value read 
before being initialized.


I don't understand why this is so hard to understand. I started 
discussing this because people where claiming that non null makes 
the compiler more complex to implement, which is completely false.


Now, as D assume all over the place that everything can be 
initialized by default, so making @disable this work require a 
larger design change than simply pluging holes. It means that as 
of now, some entities can't be initialized by default.

Re: [article] Language Design Deal Breakers

2013-05-29 Thread Walter Bright


On 5/29/2013 12:46 AM, Sergei Nosov wrote:

On Wednesday, 29 May 2013 at 07:35:43 UTC, Walter Bright wrote:

On 5/29/2013 12:01 AM, Sergei Nosov wrote:

What would be the NotNull.init.p value then?


null, but use of it is disabled.


So it breaks the ability to always make a default initialization of a struct. As
I understand, this ability was kind of important. Is there any solution for this
planned? And if no, do you provision any negative consequences?


The whole point of a notnull is to disallow default initialization.

Re: Need some opinions for a GUI editor

On Wednesday, 29 May 2013 at 07:56:19 UTC, Denis Shelomovskij 
wrote:

29.05.2013 1:25, Flamaros пишет:

Hi,

I and a friend are developing a GUI library, and now our 
script engine
is ready to start a prototype (but far to be finished). We 
think to try

to create a GUI editor based on our library.
In this way, we'll see which features are need.

My concern is about how the editor have to works, we see two 
different

ways to do it :
1) Classic editor external to the user applications
 a) Good :
- Lightweight (easy to deploy and test)
- No need to modify application code
- Stable due to isolation of application
- Real-time edition but limited on one view (bad to 
preview menus

transitions)
 b) Bad :
- Limited, plugins needed to extend editor components and 
his
knowledge of application (can't predict size of unknown 
application

specific items)

2) Integrated editor (launch with the user application in a 
second Window)

 a) Good :
- Preview is the final result with real data
- All application components accessible to the editor 
without
complex plugin system (in this way all editors components will 
be well

placed in the preview)
- Full real-time edition (can preview menus 
transitions,...)

- User can customize the editor
 b) Bad :
- Intrusive in the application code
- Force the user to port application on a desktop OS 
(Linux, Mac or
Windows), not friendly if he target only embedded devices (can 
be

bypassed with a remote system)
- Less stable editor?

The second solution is commonly used in the video game 
industry, but is

the best choice for a larger usage?

What do you think about?


As for me, a GUI editor is completely unneeded. Currently I'm 
using GTK+ for my apps so I tried to use Glade a long time ago 
but finished manually writing all the code as it:


1. It is not complicated and not time-wasted at all.
2. It gives you more control on the application.
3. It saves you time (!) as you can use you own functions for 
common widgets creation/location patterns.


So if your library isn't that silly one where you have to 
manually specify widget location/size in parent don't waste 
your time on GUI editor.


Our GUI library will be interesting for modern Interfaces with 
animations. I really think that it's easier to tweak animations 
and positions of items in real time.
The editor will not hide script code, so manual edition will be 
possible too.

Re: Inability to dup/~ for const arrays of class objects


On Wednesday, 29 May 2013 at 01:05:14 UTC, Peter Williams wrote:
I'm implementing sets and the concept is sets of objects not 
sets of the values in the objects.  I want to be able to 
initialize sets using arrays and I'm promising that I won't 
change the array or its contents.
 I'm also trying to promise that I won't (inside the set 
implementation) make any changes to individual objects.  But 
I'm not promising that they won't be changed by other code that 
has access to them.  The invariant (I wrote) for the sets 
implies that any changes made by that code can't change the 
sort order of the objects.


Peter


The problem is that you are missing a FUNDAMENTAL difference 
between C++ and D. C++'s const merely says: Though shalt not 
modify this value, whereas D's means This object's value WILL 
remain constant, until the end of time, and under no circumstance 
can it ever be modified. Oh. And so will everything it 
references.


The fact that *you* are promising to not change it is irrelevant 
to the concept of D's const. D only knows 2 states: objects that 
mutate, and objects that don't mutate.


Ditto about invariants. Contrary to C++, there is no concept of 
observable constness (eg invariants).


The reasoning behind this is that in D, const is actually the 
base attribute between the muttable and the immutable 
objects. immutable allows sharing things accross threads, and 
allows more aggressive optimizations than is possible with const 
the compiler *knows* the object will not be changed by an 
outside force. At this point, const exists only to be able to 
operate on objects that may or may not be immutable.


For example, imagine you have a const array of pointers, and you


Of course, this has its limits, and that's where casting comes 
into play. You must keep in mind these two caveats:

*Never ever ever modify something that is const.
*Once you've casted something to const, make sure that NOTHING 
will modify the object via a non-const handle.


But the const you are trying to promise is not what D's const 
was designed for.

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 08:49:24 UTC, Paulo Pinto wrote:

On Tuesday, 28 May 2013 at 21:25:05 UTC, Flamaros wrote:

Hi,

I and a friend are developing a GUI library, and now our 
script engine is ready to start a prototype (but far to be 
finished). We think to try to create a GUI editor based on our 
library.

In this way, we'll see which features are need.

My concern is about how the editor have to works, we see two 
different ways to do it :

1) Classic editor external to the user applications
a) Good :
   - Lightweight (easy to deploy and test)
   - No need to modify application code
   - Stable due to isolation of application
   - Real-time edition but limited on one view (bad to preview 
menus transitions)

b) Bad :
   - Limited, plugins needed to extend editor components and 
his knowledge of application (can't predict size of unknown 
application specific items)


2) Integrated editor (launch with the user application in a 
second Window)

a) Good :
   - Preview is the final result with real data
   - All application components accessible to the editor 
without complex plugin system (in this way all editors 
components will be well placed in the preview)

   - Full real-time edition (can preview menus transitions,...)
   - User can customize the editor
b) Bad :
   - Intrusive in the application code
   - Force the user to port application on a desktop OS 
(Linux, Mac or Windows), not friendly if he target only 
embedded devices (can be bypassed with a remote system)

   - Less stable editor?

The second solution is commonly used in the video game 
industry, but is the best choice for a larger usage?


What do you think about?


I always hold Delphi and C++ Builder as examples of a what a 
good UI editor should offer.


Currently Blend + VS are also another good examples for proper 
tooling for making good UIs.


--
Paulo


It seems Blend can directly run on top of the application. Are 
you using this feature?

Re: Why UTF-8/16 character encodings?


On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
I've recently come to the opinion that that's a bad idea, and D 
should not support it.


Honestly, removing support for non-ASCII characters from 
identifiers is the worst idea you've had in a while. There is an 
_unfathomable amount_ of code out there written in non-English 
languages but hamfisted into an English-alphabet representation 
because the programming language doesn't care to support it. The 
resulting friction is considerable.


You seem to attribute particular value to personal anecdotes, so 
here's one of mine: I personally know several prestigious 
universities in Europe and Asia which teach programming using 
Java and/or C with identifiers being in an English-alphabet 
representation of the native non-English language. Using the 
English language for identifiers is usually a sanctioned 
alternative, but not the primary modus operandi. I also know 
several professional programmers using their native non-English 
language for identifiers in production code.


Please reconsider.

Re: Inability to dup/~ for const arrays of class objects


On Wednesday, 29 May 2013 at 09:40:08 UTC, monarch_dodra wrote:

On Wednesday, 29 May 2013 at 01:05:14 UTC, Peter Williams wrote:
I'm implementing sets and the concept is sets of objects not 
sets of the values in the objects.  I want to be able to 
initialize sets using arrays and I'm promising that I won't 
change the array or its contents.
I'm also trying to promise that I won't (inside the set 
implementation) make any changes to individual objects.  But 
I'm not promising that they won't be changed by other code 
that has access to them.  The invariant (I wrote) for the sets 
implies that any changes made by that code can't change the 
sort order of the objects.


Peter


The problem is that you are missing a FUNDAMENTAL difference 
between ...


Erm, I posted this without seeing there was more to the thread. 
So I could be wrong. But I think the point is still relevant.

Re: D on next-gen consoles and for game development

2013-05-29 Thread Jacob Carlborg


On 2013-05-29 09:05, Paulo Pinto wrote:


The main reason was that the GC never worked properly given the C
underpinnings of Objective-C.

Too many libraries failed to work properly with GC enabled, plus you
needed to fill your code with GC friendly annotations.

So I imagine Apple tried to find a compromises that would work better in
a language with C safety.

Even that is only supported at the Objective-C language level and it
requires both compiler support and that objects inherit from NSObject as
top most class, as far as I am aware.

Anyway it is way better than pure manual memory management.


I'm pretty it works for their CoreFoundation framework which is a C 
library. NSObject, NSString and other classes are built on top of 
CoreFoundation.


--
/Jacob Carlborg

Re: Need some opinions for a GUI editor

2013-05-29 Thread Jacob Carlborg


On 2013-05-28 23:25, Flamaros wrote:

Hi,

I and a friend are developing a GUI library, and now our script engine
is ready to start a prototype (but far to be finished). We think to try
to create a GUI editor based on our library.
In this way, we'll see which features are need.

My concern is about how the editor have to works, we see two different
ways to do it :
1) Classic editor external to the user applications
  a) Good :
 - Lightweight (easy to deploy and test)
 - No need to modify application code
 - Stable due to isolation of application
 - Real-time edition but limited on one view (bad to preview menus
transitions)
  b) Bad :
 - Limited, plugins needed to extend editor components and his
knowledge of application (can't predict size of unknown application
specific items)

2) Integrated editor (launch with the user application in a second Window)
  a) Good :
 - Preview is the final result with real data
 - All application components accessible to the editor without
complex plugin system (in this way all editors components will be well
placed in the preview)
 - Full real-time edition (can preview menus transitions,...)
 - User can customize the editor
  b) Bad :
 - Intrusive in the application code
 - Force the user to port application on a desktop OS (Linux, Mac or
Windows), not friendly if he target only embedded devices (can be
bypassed with a remote system)
 - Less stable editor?

The second solution is commonly used in the video game industry, but is
the best choice for a larger usage?

What do you think about?


I would go with the first approach because I would guess it's easier. 
The editor creates the controls. When saving it will serialize all the 
controls to some format. This format is then read by the application.


For serialization you could have a look at Orange:

https://github.com/jacob-carlborg/orange

--
/Jacob Carlborg

Re: NoScopeStatement violates C compatibility principal.

2013-05-29 Thread bearophile


Ali Çehreli:

It is still a bug because NoScopeStatement does not mean 
expand into current scope. It means do not introduce a 
scope and clearly allows blocked statements:


NoScopeStatement:
;
NonEmptyStatement
BlockStatement


So we reopen issue 199 or we create a new one?

Bye,
bearophile

Re: Rust-based provocation :)


On Wednesday, 29 May 2013 at 01:07:58 UTC, Adam D. Ruppe wrote:

...


Thanks for doing this, very appreciated. This thread unexpectedly 
got really useful to me, now I know that there is at least one 
more D programmer interested in this :) Won't be really able to 
test it until next week, but have added to bookmarks.


My main interest here is to get something running to experiment 
with what changes can be made to compiler to allow to remove 
unused stubs and still get the useful stuff running. Like no 
exceptions and no rtti switches in g++.

Re: Why UTF-8/16 character encodings?

2013-05-29 Thread Marco Leise

Am Mon, 27 May 2013 16:05:46 -0700
schrieb Walter Bright newshou...@digitalmars.com:

 On 5/27/2013 3:18 PM, H. S. Teoh wrote:
  Well, D *does* support non-English identifiers, y'know... for example:
 
  void main(string[] args) {
  int число = 1;
  foreach (и; 0..100)
  число += и;
  writeln(число);
  }
 
  Of course, whether that's a good practice is a different story. :)
 
 I've recently come to the opinion that that's a bad idea, and D should not 
 support it.

I hope that was just a random thought. I knew a teacher who
would give all his methods German names so they are easier to
distinguish from the English Java library methods.
Personally I like to type α instead of alpha for angles, since
that is the identifier you'd expect in math. And everyone
likes alias ℕ = size_t;, right? :) Déjà vu?

-- 
Marco

Re: NoScopeStatement violates C compatibility principal.


On Wednesday, 29 May 2013 at 09:51:58 UTC, bearophile wrote:

Ali Çehreli:

It is still a bug because NoScopeStatement does not mean 
expand into current scope. It means do not introduce a 
scope and clearly allows blocked statements:


NoScopeStatement:
   ;
   NonEmptyStatement
   BlockStatement


So we reopen issue 199 or we create a new one?

Bye,
bearophile


I reopened it. Its not a new issue, so I don't think it warrants 
a new thread.


EDIT: I did file this though, which is kind of related: 
http://d.puremagic.com/issues/show_bug.cgi?id=10199

Re: Why UTF-8/16 character encodings?

2013-05-29 Thread Torje Digernes


On Tuesday, 28 May 2013 at 01:17:37 UTC, H. S. Teoh wrote:

On Tue, May 28, 2013 at 02:54:30AM +0200, Torje Digernes wrote:

On Tuesday, 28 May 2013 at 00:34:20 UTC, Manu wrote:
On 28 May 2013 09:05, Walter Bright 
newshou...@digitalmars.com

wrote:

On 5/27/2013 3:18 PM, H. S. Teoh wrote:

Well, D *does* support non-English identifiers, y'know... 
for

example:

void main(string[] args) {
int число = 1;
foreach (и; 0..100)
число += и;
writeln(число);
}

Of course, whether that's a good practice is a different
story. :)


I've recently come to the opinion that that's a bad idea, 
and D

should not
support it.


Why? You said previously that you'd love to support extended
operators ;)

I find features such as support for uncommon symbols in 
variables a
strength as it makes some physics formulas a bit easier to 
read in

code form, which in my opinion is a good thing.


I think there's a difference between allowing math symbols 
(which
includes things like (a subset of) Greek letters that 
mathematicians
love) in identifiers, and allowing full Unicode. What if you're 
assigned
to maintain code containing identifiers that has letters that 
don't

appear in any of your installed fonts?

I think it's OK to allow math symbols, but allowing the entire 
set of
Unicode characters is going a bit too far, IMO. For one thing, 
if some
code has identifiers written in Arabic, I wouldn't be able to 
understand

the code, simply because I'd have a hard time telling different
identifiers apart.  Besides, if the rest of the language 
(keywords,
Phobos, etc.) are in English, then I don't see any compelling 
reason to
use a different language in identifiers, other than to submit 
IODCC

entries. :-P

C doesn't support Unicode identifiers, for one thing, but I've 
seen
working C code written by people who barely understand any 
English -- it
didn't stop them at all. (The comments were of course in their 
native
language -- the compiler ignores everything inside anyway so 
8-bit
native encodings or even UTF-8 can be sneaked in without 
provoking

compiler errors.)


T
I think there is very little difference, both cases are 
artificially limiting the allowable symbols. Other symbols 
relevant in other fields which does not happen to use Greek 
symbols primarily, are they to be treated differently?


What you propose is a built in code standard for D, based on your 
feelings on a topic.


If what you fear is that unicode will suddenly make cooperation 
impossible I doubt you are right, after all there is all kind of 
ways to make terrible variable names (q,w,e,r ... qq,qw). If any 
such identifiers show up in a project I assume they are cleaned 
up, why wouldn't the same happen to unicode if they are causing 
problems? Think about it, it should happen even faster because 
the symbol might not be accessible for everyone, where a 
single/double letter gibberish one is perfectly reproducible and 
might grow into the project confusing every new reader. Are you 
going to argue for disallowing variables that are not a compound 
word or a dictionary word in English?

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 09:51:04 UTC, Jacob Carlborg wrote:

On 2013-05-28 23:25, Flamaros wrote:

Hi,

I and a friend are developing a GUI library, and now our 
script engine
is ready to start a prototype (but far to be finished). We 
think to try

to create a GUI editor based on our library.
In this way, we'll see which features are need.

My concern is about how the editor have to works, we see two 
different

ways to do it :
1) Classic editor external to the user applications
 a) Good :
- Lightweight (easy to deploy and test)
- No need to modify application code
- Stable due to isolation of application
- Real-time edition but limited on one view (bad to 
preview menus

transitions)
 b) Bad :
- Limited, plugins needed to extend editor components and 
his
knowledge of application (can't predict size of unknown 
application

specific items)

2) Integrated editor (launch with the user application in a 
second Window)

 a) Good :
- Preview is the final result with real data
- All application components accessible to the editor 
without
complex plugin system (in this way all editors components will 
be well

placed in the preview)
- Full real-time edition (can preview menus 
transitions,...)

- User can customize the editor
 b) Bad :
- Intrusive in the application code
- Force the user to port application on a desktop OS 
(Linux, Mac or
Windows), not friendly if he target only embedded devices (can 
be

bypassed with a remote system)
- Less stable editor?

The second solution is commonly used in the video game 
industry, but is

the best choice for a larger usage?

What do you think about?


I would go with the first approach because I would guess it's 
easier. The editor creates the controls. When saving it will 
serialize all the controls to some format. This format is then 
read by the application.


For serialization you could have a look at Orange:

https://github.com/jacob-carlborg/orange


You think it's easier to do or to use?


We can't do serialization because our GUI files are lua scripts.

It looks like :
[CODE]
Image {
id = image,
source = images/pngtest.png,
x = 50,
y = 50,

titi = 0,
toto = function()
return image.width + image.height
end,
onTotoChanged = function()
image.titi = image.toto
print(onTotoChanged = ..image.titi) 
end,

Button {
width = function()
return image.width
end,
height = function()
return image.height
end,
}
}
[/CODE]

Button isn't a D Object :
[CODE]
function Button(t)
print(t.width)
local Buttonimage3 = Image {
id = Buttonimage,
		width = 100,	-- property binding, when image change width is 
automatically updated

height = 50,
-- opGet = function(propertyName)
-- return ButtonmouseArea[propertyName]
-- end,
-- opSet = function(propertyName, value)
-- ButtonmouseArea[propertyName] = value
-- end,


source = function ()
			if ButtonmouseArea.pressed then	-- property binding, when 
mouseArea state change this condition is updated directly

return images/Alpha-blue-trans.png
else
return images/pngtest.png
end
end,

MouseArea { -- parent/child 
object encapsulation
id = ButtonmouseArea,
width = function ()
return Buttonimage.width
end,
height = function ()
return Buttonimage.height
end,
},
}
for key, value in pairs(t) do
print(value)
Buttonimage3[key] = value
end
return Buttonimage3
end
[/CODE]

Re: Why UTF-8/16 character encodings?

2013-05-29 Thread qznc


On Tuesday, 28 May 2013 at 00:11:18 UTC, Walter Bright wrote:

On 5/27/2013 4:28 PM, Hans W. Uhlig wrote:

On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
I've recently come to the opinion that that's a bad idea, and 
D should not

support it.


Why do you think its a bad idea? It makes it such that code 
can be in various

languages? Just lack of keyboard support?


Every time I've been to a programming shop in a foreign 
country, the developers speak english at work and code in 
english. Of course, that doesn't mean that everyone does, but 
as far as I can tell the overwhelming bulk is done in english.


Naturally, full Unicode needs to be in strings and comments, 
but symbol names? I don't see the point nor the utilty of it. 
Supporting such is just pointless complexity to the language.


Once I heared an argument from developers working for banks. They 
coded business-specific stuff in Java. Business-specific meant 
financial concepts with german names (e.g. Vermögen,Bürgschaft), 
which sometimes include äöüß. Some of those concept had no good 
translation into english, because they are not used outside of 
Germany and the clients prefer the actual names anyways.

Re: I may have found a bug.


On Wednesday, 29 May 2013 at 07:32:42 UTC, Jeremy DeHaan wrote:

Thoughts?


static variables are thread local. Are you sure the destructor 
run in the same thread as the constructor ?

Re: Canonical/Idiomatic in memory files

2013-05-29 Thread Russel Winder

On Wed, 2013-05-29 at 00:32 -0700, Walter Bright wrote:
[…]
 This is incorrect. They are implemented as sort of second class citizens in 
 the current name space. This means that any declaration in the current name 
 space overrides any in the import name space. If the name is not found in the 
 current name space, and is found in more than one import, an ambiguity error 
 is 
 generated.

OK so this is a quasi-namespace import which helps. Dealing with
multiple names in imports by just creating a compile error stops tragedy
but seems a little awkward. It does reinforce my belief in individual
importing of names though.

[…]
 It's equivalent to:
 struct Tuple { int lines; int words; int chars; }
 which is much more efficient than a dictionary.

Interesting. I probably should already have known this. I suspect
further exchanges on this should move the to learn mailing list!

[…]
 You just need to get the component programming religion! and get away from 
 using 
 FILE*. There isn't anything fundamentally different from using a fake FILE* 
 and 
 using a template with a different InputRange. If that's still unacceptable, 
 you 
 can create an InputRange that is a class with virtual functions empty(), 
 front(), and popFront(), then use derived classes for the File or string.

I'm not sure I would call it component – didn't components die in the
1980 when no-one could agree what a component was?

I had missed that there was the possibility of polymorphism over
sequence of strings and open file. Which is silly as that is exactly
what you can do in Python and which I do a lot. Doh moment.

Thanks.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: I may have found a bug.


On Wednesday, 29 May 2013 at 10:33:32 UTC, deadalnix wrote:

On Wednesday, 29 May 2013 at 07:32:42 UTC, Jeremy DeHaan wrote:

Thoughts?


static variables are thread local. Are you sure the destructor 
run in the same thread as the constructor ?


Either way remove should simply fail not give a memory error.

Re: I may have found a bug.


On Wednesday, 29 May 2013 at 10:33:32 UTC, deadalnix wrote:

On Wednesday, 29 May 2013 at 07:32:42 UTC, Jeremy DeHaan wrote:

Thoughts?


static variables are thread local. Are you sure the destructor 
run in the same thread as the constructor ?


Actually it fails because _aaDelX calls gc, and gc is not 
reenterable. It has nothing to do with static or thread locals.

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 10:22:21 UTC, Flamaros wrote:

We can't do serialization because our GUI files are lua scripts.


Just curious, but, are you using LuaD?

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 09:40:33 UTC, Flamaros wrote:

On Wednesday, 29 May 2013 at 08:49:24 UTC, Paulo Pinto wrote:

On Tuesday, 28 May 2013 at 21:25:05 UTC, Flamaros wrote:

Hi,

I and a friend are developing a GUI library, and now our 
script engine is ready to start a prototype (but far to be 
finished). We think to try to create a GUI editor based on 
our library.

In this way, we'll see which features are need.

My concern is about how the editor have to works, we see two 
different ways to do it :

1) Classic editor external to the user applications
a) Good :
  - Lightweight (easy to deploy and test)
  - No need to modify application code
  - Stable due to isolation of application
  - Real-time edition but limited on one view (bad to preview 
menus transitions)

b) Bad :
  - Limited, plugins needed to extend editor components and 
his knowledge of application (can't predict size of unknown 
application specific items)


2) Integrated editor (launch with the user application in a 
second Window)

a) Good :
  - Preview is the final result with real data
  - All application components accessible to the editor 
without complex plugin system (in this way all editors 
components will be well placed in the preview)

  - Full real-time edition (can preview menus transitions,...)
  - User can customize the editor
b) Bad :
  - Intrusive in the application code
  - Force the user to port application on a desktop OS 
(Linux, Mac or Windows), not friendly if he target only 
embedded devices (can be bypassed with a remote system)

  - Less stable editor?

The second solution is commonly used in the video game 
industry, but is the best choice for a larger usage?


What do you think about?


I always hold Delphi and C++ Builder as examples of a what a 
good UI editor should offer.


Currently Blend + VS are also another good examples for proper 
tooling for making good UIs.


--
Paulo


It seems Blend can directly run on top of the application. Are 
you using this feature?


What you mean by run on top ?

I use it to have a look if everything looks like and for some 
stuff I need to execute the application but it requires runtime 
information.


Blend can work with VS solutions and also invoke MSBuild, but if 
you are doing custom controls and stuff it is better to do 
certain parts from VS side, hence using both.


--
Paulo

Re: D on next-gen consoles and for game development

2013-05-29 Thread Michel Fortin


On 2013-05-29 08:06:15 +, Manu turkey...@gmail.com said:


What do you think is easier, or perhaps even POSSIBLE in D?
A good RC approach, or a V8 quality concurrent+incremental GC?
I get the feeling either would be acceptable, but I still kinda like idea
of the determinism an RC collector offers.


Given that both require calling a function of some sort on pointer 
assignment, I'd say they're pretty much equivalent in implementation 
effort. One thing the compiler should do with RC that might require 
some effort is cancel out redundant increments/decrement pairs inside 
functions, and also offer some kind of weak pointer to deal with 
cycles. On the GC side, well you have to write the new GC.


Also, with RC, you have to be careful not to create cycles with 
closures. Those are often hard to spot absent of an explicit list of 
captured variables.


--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/

Re: D on next-gen consoles and for game development

2013-05-29 Thread Michel Fortin

On 2013-05-29 09:46:20 +, Jacob Carlborg d...@me.com said:

On 2013-05-29 09:05, Paulo Pinto wrote:

The main reason was that the GC never worked properly given the C
underpinnings of Objective-C.

Too many libraries failed to work properly with GC enabled, plus you
needed to fill your code with GC friendly annotations.

So I imagine Apple tried to find a compromises that would work better in
a language with C safety.

Even that is only supported at the Objective-C language level and it
requires both compiler support and that objects inherit from NSObject as
top most class, as far as I am aware.

Anyway it is way better than pure manual memory management.

I'm pretty it works for their CoreFoundation framework which is a C
library. NSObject, NSString and other classes are built on top of
CoreFoundation.

It does for CF types which are toll-free bridged, if you mark them to
be GC managed while casting.

http://developer.apple.com/library/ios/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html

For

instance, CFString and NSString are just different APIs for the same
underlying object, so you can cast between them. But CoreFoundation
itself won't use the GC if you don't involve Objective-C APIs. The
interesting thing is that objects managed by the now deprecated
Objective-C GC also have a reference count, and won't be candidate for
garbage collection until the reference count reaches zero. You can use
CFRetain/CFRelease on GC-managed Objective-C objects if you want, it's
not a noop.

--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/

Re: Canonical/Idiomatic in memory files


On Wednesday, 29 May 2013 at 11:00:23 UTC, Russel Winder wrote:

On Wed, 2013-05-29 at 00:32 -0700, Walter Bright wrote:
[…]
This is incorrect. They are implemented as sort of second 
class citizens in the current name space. This means that any 
declaration in the current name space overrides any in the 
import name space. If the name is not found in the current 
name space, and is found in more than one import, an ambiguity 
error is generated.


OK so this is a quasi-namespace import which helps. Dealing with
multiple names in imports by just creating a compile error 
stops tragedy
but seems a little awkward. It does reinforce my belief in 
individual

importing of names though.

[…]

It's equivalent to:
struct Tuple { int lines; int words; int chars; }
which is much more efficient than a dictionary.


Interesting. I probably should already have known this. I 
suspect

further exchanges on this should move the to learn mailing list!

[…]
You just need to get the component programming religion! and 
get away from using FILE*. There isn't anything fundamentally 
different from using a fake FILE* and using a template with a 
different InputRange. If that's still unacceptable, you can 
create an InputRange that is a class with virtual functions 
empty(), front(), and popFront(), then use derived classes for 
the File or string.


I'm not sure I would call it component – didn't components die 
in the

1980 when no-one could agree what a component was?



They reborned in the form of interface based programming, COM and 
Web APIs.

Re: [article] Language Design Deal Breakers


On Wednesday, 29 May 2013 at 04:15:52 UTC, Walter Bright wrote:

It's not in Phobos yet:


I did a pull request a while ago that stalled for some reason I 
don't remember now, but the struct I did needed to be a little 
more complex than yours to pass all the tests


==

struct NotNull(T) if(__traits(compiles, { T t; assert(t is null); 
}))

{
private T _notNullData;
@property inout(T) _notNullDataHelper() inout
{
assert(_notNullData !is null); // sanity check of 
invariant

return _notNullData;
}
// Apparently a compiler bug - the invariant being 
uncommented breaks all kinds of stuff.

// invariant() { assert(_notNullData !is null); }

alias _notNullDataHelper this; /// this is substitutable for 
the regular (nullable) type

@disable this();

// this could arguably break the static type check because
// you can assign it from a variable that is null.. but I
// think it is important that NotNull!Object = new Object();
// works, without having to say assumeNotNull(new Object())
// for convenience of using with local variables.

/// constructs with a runtime not null check (via assert())
this(T value)
{
assert(value !is null);
_notNullData = value;
}

@disable this(typeof(null)); /// the null literal can be 
caught at compile time

@disable typeof(this) opAssign(typeof(null)); /// ditto

/// .
NotNull!T opAssign(NotNull!T rhs)
{
this._notNullData = rhs._notNullData;
return this;
}
}




/// A convenience function to construct a NotNull value from 
something you know isn't null.

NotNull!T assumeNotNull(T)(T t)
{
return NotNull!T(t); // note the constructor asserts it is 
not null

}

/// A convenience function to check for null. If you pass null, 
it will throw an exception. Otherwise, return NotNull!T.

NotNull!T enforceNotNull(T)(T t)
{
enforce(t !is null);
return NotNull!T(t);
}

unittest
{
import core.exception;
import std.exception;

void NotNullCompiliationTest1()() // I'm making these 
templates to defer compiling them

{
NotNull!(int*) defaultInitiliation; // should fail 
because this would be null otherwise

}
assert(!__traits(compiles, NotNullCompiliationTest1!()()));

void NotNullCompiliationTest2()()
{
NotNull!(int*) defaultInitiliation = null; // should fail 
here too at compile time

}
assert(!__traits(compiles, NotNullCompiliationTest2!()()));

int dummy;
NotNull!(int*) foo = dummy;

assert(!__traits(compiles, foo = null)); // again, literal 
null is caught at compile time


int* test;

test = dummy;

foo = assumeNotNull(test); // should be fine

void bar(int* a) {}

// these should both compile, since NotNull!T is a subtype of 
T

bar(test);
bar(foo);

void takesNotNull(NotNull!(int*) a) { }

assert(!__traits(compiles, takesNotNull(test))); // should 
not work; plain int might be null

takesNotNull(foo); // should be fine

takesNotNull(assumeNotNull(test)); // this should work too
assert(!__traits(compiles, 
takesNotNull(assumeNotNull(null; // notNull(null) shouldn't 
compile

test = null; // reset our pointer

assertThrown!AssertError(takesNotNull(assumeNotNull(test))); 
// test is null now, so this should throw an assert failure


void takesConstNotNull(in NotNull!(int *) a) {}

test = dummy; // make it valid again
takesConstNotNull(assumeNotNull(test)); // should Just Work

NotNull!(int*) foo2 = foo; // we should be able to assign 
NotNull to other NotNulls too

foo2 = foo; // including init and assignment
}



=



One thing I wasn't quite happy with  was a lot of people request:

if(a !is null) {
 // a is now NotNull!T
}


Of course, that directly won't work, but maybe we can get close. 
Best I could do was


if(a !is null) {
  auto a2 = assumeNotNull(a);
  // use a2 instead
}


which isn't quite what people wanted, but it is simple and works.

Re: [article] Language Design Deal Breakers

BTW I'm now doing a whole module based on @disable this() that 
includes cool stuff like bounded int/float values (including 
runtime overflow checks, if needed). Actually I wrote much of 
this over a year ago too, but now starting to organize it.


The disabled default constructor is pretty nice for a lot of 
things.

Re: [article] Language Design Deal Breakers


On Wednesday, 29 May 2013 at 09:28:38 UTC, Walter Bright wrote:
The whole point of a notnull is to disallow default 
initialization.


Beg my pardon if that was already discussed by how does that 
interfere with various T.init use cases in current code? Most 
important, won't some existing template constraints wrongly fail 
for such types?

Re: [article] Language Design Deal Breakers


Another outside POV..

On Wed, 29 May 2013 10:20:39 +0100, deadalnix deadal...@gmail.com wrote:

On Wednesday, 29 May 2013 at 07:50:39 UTC, Kenji Hara wrote:

Currently I recognize that it is necessary to fix compiler bugs around
@disable this(); at least.

@deadalnix, it seems to me that you argue that @disable this(); is
insufficient or useless to implement NotNull!T. If so, what is  
necessary to

do it? What is impossible thing by NotNullT?



No I'm nto saying that this is impossible, I'm saying that @disable  
this() and non nullable pointer are the exact same feature.


To implement both, the compiler have to track initialization of the  
value and yell at you if it isn't done, or if the value read before  
being initialized.


I don't understand why this is so hard to understand.


It's not.  Everyone understands this point, it's not the point of  
contention.


I started discussing this because people where claiming that non null  
makes the compiler more complex to implement, which is completely false.


That's not the argument being made by Simen.  The argument is that  
@disable this() is a feature which allows a set of features which include  
but is not limited to not-null, and is therefore a superior feature to  
have.


Do you agree?

IMO, this then renders any specific not-null language feature  
unnecessary.  And, allows a library type to do the job.


Now, as D assume all over the place that everything can be initialized  
by default, so making @disable this work require a larger design change  
than simply pluging holes. It means that as of now, some entities can't  
be initialized by default.


Assuming, as you say, that @disable this() and not-null require the same  
compiler work, these holes that need plugging would need plugging in  
either case, right?


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Inability to dup/~ for const arrays of class objects


On Wednesday, 29 May 2013 at 09:40:08 UTC, monarch_dodra wrote:
whereas D's means This object's value WILL remain constant, 
until the end of time, and under no circumstance can it ever be 
modified. Oh. And so will everything it references.


That's NOT what D's const means! The data may change through 
other, mutable references to it, but not through any const 
references. That's why const data is not implicitly convertible 
to immutable data (unless it has no mutable indirection, in which 
case it would be a deep copy) - there could be mutable references 
out there!


The difference between C++ and D const is that D's const is 
transitive, and mutating it by casting away const can have 
terrible consequences because const is designed to work with 
immutable.


The fact that *you* are promising to not change it is 
irrelevant to the concept of D's const. D only knows 2 states: 
objects that mutate, and objects that don't mutate.


No.

*Once you've casted something to const, make sure that NOTHING 
will modify the object via a non-const handle.


This is *perfectly fine* unless the non-const handle was acquired 
by casting away const or immutable.

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 11:11:36 UTC, Jakob Ovrum wrote:

On Wednesday, 29 May 2013 at 10:22:21 UTC, Flamaros wrote:
We can't do serialization because our GUI files are lua 
scripts.


Just curious, but, are you using LuaD?


Nop, I use lua directly (but loaded with derelict).

Can LuaD manage metatables and other advanced features?

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 12:31:51 UTC, Flamaros wrote:

Nop, I use lua directly (but loaded with derelict).

Can LuaD manage metatables and other advanced features?


Yes! :)

it's intended as a no-compromise wrapper of the C API.

Re: Inability to dup/~ for const arrays of class objects


On Wednesday, 29 May 2013 at 12:23:04 UTC, Jakob Ovrum wrote:

On Wednesday, 29 May 2013 at 09:40:08 UTC, monarch_dodra wrote:
whereas D's means This object's value WILL remain constant, 
until the end of time, and under no circumstance can it ever 
be modified. Oh. And so will everything it references.


That's NOT what D's const means! The data may change through 
other, mutable references to it, but not through any const 
references. That's why const data is not implicitly convertible 
to immutable data (unless it has no mutable indirection, in 
which case it would be a deep copy) - there could be mutable 
references out there!


The difference between C++ and D const is that D's const is 
transitive, and mutating it by casting away const can have 
terrible consequences because const is designed to work with 
immutable.


The fact that *you* are promising to not change it is 
irrelevant to the concept of D's const. D only knows 2 states: 
objects that mutate, and objects that don't mutate.


No.

*Once you've casted something to const, make sure that NOTHING 
will modify the object via a non-const handle.


This is *perfectly fine* unless the non-const handle was 
acquired by casting away const or immutable.


Hum.

...

Sight. I think I let immutable get to my head again :/

You are right. My point was moot.

Const initialization issue, looking for solution


Consider the following example:

http://dpaste.dzfl.pl/a0595ddf

// Can throw, and we want to catch
int createTheVar();

// Can also throw, but we don't want to catch it here
int transform(int a);

int foo()
{
const(int) i;

try
{
i = createTheVar(); // Clearly not allowed
}
catch(Exception e) // For demo purposes
{
// Exception handling code
}

return transform(i);
}

I need to be able to catch an exception that may have been thrown 
during the initialization of `i`, but still have `i` be const. I 
can't omit the variable because I *don't* want to accidentally 
catch anything that transform() may have thrown.


Note that the simple type const(int) is an example. This is 
actually in highly generic code and the type may have mutable 
indirection.


Here's the real-world code:
https://github.com/JakobOvrum/LuaD/blob/master/luad/conversions/functions.d#L86

The particular problematic type I happened to encounter for 
RetType is the const(CacheInfo)[5] return type of 
core.cpuid.dataCaches:

http://dlang.org/phobos/core_cpuid.html#.dataCaches

Specifics aside, I believe this is a very general problem.


Of course, if D had well-defined, local flow analysis like many 
other modern languages (e.g. C#), this code would not have to be 
rejected. I think that's a discussion for the future though; 
right now it would be nice to have a workable, general 
solution/workaround to the issue of initializing const/immutable 
variables in try-blocks.


Any help is much appreciated.

Re: Const initialization issue, looking for solution


Why something like this is not usable?
---
int tmp;
try
{
   tmp = ...;
}
catch(..)
{
}
const(int) i = tmp;
---
Not really pretty but nothing crazy.

Re: Rust-based provocation :)


On Wednesday, 29 May 2013 at 09:58:02 UTC, Dicebot wrote:
My main interest here is to get something running to experiment 
with what changes can be made to compiler to allow to remove 
unused stubs and still get the useful stuff running. Like no 
exceptions and no rtti switches in g++.


That might be possible through -version switches on object.d, 
which would give either a stub (my original d_throw function 
before copy/pasting from druntime just said { write(exception 
thrown); exit(1); } or something like that) or left out 
entirely, leading to linker errors.


The same thing might be possible for more features.


BTW I just tried new int[](10), and that needs even more code. 
But I think using that in a non-gc environment is actually a 
mistake anyway. It could be done like classes, where the new 
function mallocs and you are responsible for freeing, but the 
problem is new int[](10) and arr[0 .. 10] look the same in user 
code.


You would be responsible for freeing the former, but not the 
slice. So I think keeping them a different type is a feature, not 
a bug, in this situation.


My thought is array slices are always borrowed references. You 
don't free them, and you should avoid keeping a copy of it unless 
that is well documented. (Actually I think this would be nice 
addition to D proper, a special type qualifier that promises 
you'll never store a reference to this except in local variables. 
So you can still slice it and so on, but never stuff it in a 
member variable because the owner might free it without informing 
you.)


Anyway the arrays themselves are a different library type

StackArray!int blah;
HeapArray!int blah;

and so on, and you've gotta be responsible for freeing them 
appropriately. The StackArray of course dies when it goes out of 
scope, and maybe the HeapArray could be reference counted. Again, 
built in slices won't count toward the count, so can only use 
them temporarily, but the rest could be.



And when this is written it might be a good idea to put in phobos 
too!

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 11:36:54 UTC, Paulo Pinto wrote:

On Wednesday, 29 May 2013 at 09:40:33 UTC, Flamaros wrote:

On Wednesday, 29 May 2013 at 08:49:24 UTC, Paulo Pinto wrote:

On Tuesday, 28 May 2013 at 21:25:05 UTC, Flamaros wrote:

Hi,

I and a friend are developing a GUI library, and now our 
script engine is ready to start a prototype (but far to be 
finished). We think to try to create a GUI editor based on 
our library.

In this way, we'll see which features are need.

My concern is about how the editor have to works, we see two 
different ways to do it :

1) Classic editor external to the user applications
a) Good :
 - Lightweight (easy to deploy and test)
 - No need to modify application code
 - Stable due to isolation of application
 - Real-time edition but limited on one view (bad to preview 
menus transitions)

b) Bad :
 - Limited, plugins needed to extend editor components and 
his knowledge of application (can't predict size of unknown 
application specific items)


2) Integrated editor (launch with the user application in a 
second Window)

a) Good :
 - Preview is the final result with real data
 - All application components accessible to the editor 
without complex plugin system (in this way all editors 
components will be well placed in the preview)

 - Full real-time edition (can preview menus transitions,...)
 - User can customize the editor
b) Bad :
 - Intrusive in the application code
 - Force the user to port application on a desktop OS 
(Linux, Mac or Windows), not friendly if he target only 
embedded devices (can be bypassed with a remote system)

 - Less stable editor?

The second solution is commonly used in the video game 
industry, but is the best choice for a larger usage?


What do you think about?


I always hold Delphi and C++ Builder as examples of a what a 
good UI editor should offer.


Currently Blend + VS are also another good examples for 
proper tooling for making good UIs.


--
Paulo


It seems Blend can directly run on top of the application. Are 
you using this feature?


What you mean by run on top ?

I use it to have a look if everything looks like and for some 
stuff I need to execute the application but it requires runtime 
information.


Blend can work with VS solutions and also invoke MSBuild, but 
if you are doing custom controls and stuff it is better to do 
certain parts from VS side, hence using both.


--
Paulo


Do blend works with C++?
I don't know how it run on top but on the documentation page 
tell that it can be aware of states that are normally only on 
run-time. Maybe with a static introspection or like we propose 
with the intrusive way.

Re: Const initialization issue, looking for solution

P.S. For const reference types we have Rebindable in std.typecons 
AFAIR

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 12:40:39 UTC, Dicebot wrote:

Why something like this is not usable?
---
int tmp;
try
{
   tmp = ...;
}
catch(..)
{
}
const(int) i = tmp;
---
Not really pretty but nothing crazy.


const(int) i = tmp; // fails when the type has mutable 
indirection.

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 12:42:11 UTC, Dicebot wrote:
P.S. For const reference types we have Rebindable in 
std.typecons AFAIR


I can't imagine how it would work with non-class and 
non-interface references, like references embedded in const 
struct instances or const static arrays of such structs.

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 12:37:51 UTC, Jakob Ovrum wrote:

On Wednesday, 29 May 2013 at 12:31:51 UTC, Flamaros wrote:

Nop, I use lua directly (but loaded with derelict).

Can LuaD manage metatables and other advanced features?


Yes! :)

it's intended as a no-compromise wrapper of the C API.


Maybe you'll do a pull request to migrate to luaD when we'll open 
the repository.


For the moment, we prefer to restrict such modifications because 
we have some features to add the declaration engine. We also 
think to create a converter from a simplified syntax to the full 
lua syntax.

Re: Rust-based provocation :)


On Wednesday, 29 May 2013 at 12:41:25 UTC, Adam D. Ruppe wrote:
You would be responsible for freeing the former, but not the 
slice. So I think keeping them a different type is a feature, 
not a bug, in this situation.


I have been thinking about this long time ago. Clearly, slice 
semantics will change in GC-less environment and will require 
more restrictive operation set. No automatic slice concatenation 
at the very least.


(Actually I think this would be nice addition to D proper, a 
special type qualifier that promises you'll never store a 
reference to this except in local variables. So you can still 
slice it and so on, but never stuff it in a member variable 
because the owner might free it without informing you.)


Isn't it what scope was supposed to be all about? :) Qualifier 
that prohibits leaking data outside of the current scope.


And when this is written it might be a good idea to put in 
phobos too!


Dunno. If something like this can be done, it will need full 
re-implementation of standard library (similar to minlibd) as 
assumption made about feature set allowed and druntime differ a 
lot.

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 12:48:15 UTC, Flamaros wrote:
Maybe you'll do a pull request to migrate to luaD when we'll 
open the repository.


I will, I imagine it would be a pleasure. Deleting all that 
tedious, bug-prone stack-based code and replacing it with 
spurious, declarative one-liners sounds like a lot of fun ;)

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 12:43:46 UTC, Jakob Ovrum wrote:
const(int) i = tmp; // fails when the type has mutable 
indirection.


Ah, I understand that know. Well, until flow analysis is here I 
am afraid you can't really do anything better than assumeUnique 
or similar utility function.

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 12:54:24 UTC, Dicebot wrote:
Ah, I understand that know. Well, until flow analysis is here I 
am afraid you can't really do anything better than assumeUnique 
or similar utility function.


I'm hoping there's a way to restructure the code so it works 
(making it more functional or whatever), but I can't for the life 
of me think of a way :


Maybe leveraging another function, hopefully a Phobos function 
(like std.exception ones), can solve the issue neatly...

Re: [article] Language Design Deal Breakers


On Wednesday, 29 May 2013 at 12:19:54 UTC, Regan Heath wrote:
I started discussing this because people where claiming that 
non null makes the compiler more complex to implement, which 
is completely false.


That's not the argument being made by Simen.  The argument is 
that @disable this() is a feature which allows a set of 
features which include but is not limited to not-null, and is 
therefore a superior feature to have.


Do you agree?



I do agree that @disable this is useful. *BUT* the argument made 
is based on the untold assumption that both are mutually 
exclusive, which is not true.


IMO, this then renders any specific not-null language feature 
unnecessary.  And, allows a library type to do the job.




Most people agree that you'll find 2 useful behavior : non 
nullable and nullable with obligation of handling the null case. 
The default behavior right now provide none of thoses. It behave 
just as if it were non nullable, and simply crash when they 
happen to be null.


This behavior isn't useful. You'll find no argument except 
historical reason (which is a very valid argument BTW) to keep 
that. Everything else is backward rationalization.


Assuming, as you say, that @disable this() and not-null require 
the same compiler work, these holes that need plugging would 
need plugging in either case, right?




Yes.

Re: [article] Language Design Deal Breakers

2013-05-29 Thread Dmitry Olshansky


29-May-2013 16:18, Dicebot пишет:

On Wednesday, 29 May 2013 at 09:28:38 UTC, Walter Bright wrote:

The whole point of a notnull is to disallow default initialization.


Beg my pardon if that was already discussed by how does that interfere
with various T.init use cases in current code? Most important, won't
some existing template constraints wrongly fail for such types?


IMHO lvalueOf!T and rvalueOf!T are the only things a template 
constraints should care about. Both can be emulated with dummy functions 
that never get linked anyway. I think Denis proposed those long ago as a 
pull and we should have had them by now.


In fact most of Phobos they already use in place lambdas to get mock 
l-values of type T.


This begs the question of usefulness of T.init and should ALL types have 
it.


Since we have @disable this() I'd say T.init is no longer as useful and 
general at best it defines binary mask to blit over uninitialized 
variables. In essence it's T.uninitialized.


--
Dmitry Olshansky

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 12:43:46 UTC, Jakob Ovrum wrote:

On Wednesday, 29 May 2013 at 12:40:39 UTC, Dicebot wrote:

Why something like this is not usable?
---
int tmp;
try
{
  tmp = ...;
}
catch(..)
{
}
const(int) i = tmp;
---
Not really pretty but nothing crazy.


const(int) i = tmp; // fails when the type has mutable 
indirection.


I guess the first assignment of a variable should be considered 
as a declaration unless it has been read in between. This is the 
same problem as immutable constructor, and also relate to extra 
copies elimination.

Re: [article] Language Design Deal Breakers


On Wednesday, 29 May 2013 at 13:15:48 UTC, Dmitry Olshansky wrote:

...


Actually as I can see, at least part of Phobos uses void instead 
of T.init, but, anyway, won't this break for types with proper 
@disable this?

--
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = void;   // error?
if (r.empty) {}
r.popFront();
auto h = r.front;
}));
}

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 12:36:19 UTC, Jakob Ovrum wrote:
I need to be able to catch an exception that may have been 
thrown during the initialization of `i`, but still have `i` be 
const. I can't omit the variable because I *don't* want to 
accidentally catch anything that transform() may have thrown.


Note that the simple type const(int) is an example. This is 
actually in highly generic code and the type may have mutable 
indirection.


Fundamental issue here is that

const T t;

is almost useless, it is essentially immutable since you cannot 
change it and you cannot alias it. As such, it probably should be 
changed to a mutable object or an immutable one.


However, since const/mutable aliasing is allowed, you can do:

union U (T)
{
   const T ct;
   T mt;
}

because const doesn't mean that object would never change, you 
can mutate it through alias. From the opposite view, there is 
also no problem in reinterpeting a mutable object as const object 
(since mutables can be converted to const).


Depending on your mutable indirection situation this can work or 
may not.

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 13:19:34 UTC, deadalnix wrote:
I guess the first assignment of a variable should be considered 
as a declaration unless it has been read in between. This is 
the same problem as immutable constructor, and also relate to 
extra copies elimination.


Yeah, and languages like C# solve these problems quite 
beautifully. I don't think there's a reason we can't do almost 
the same thing in D, except it requires implementation effort and 
overcoming Walter's protests. Regardless, it's probably not 
something to expect in the short-term.



I was unable to leverage std.exception. collectException looks 
promising at first glance - and maybe if the return value and out 
parameter were switched, it would work - but then I suspect the 
function's implementation would face exactly the same problem.

Re: Rust-based provocation :)


On Wednesday, 29 May 2013 at 12:50:36 UTC, Dicebot wrote:
I have been thinking about this long time ago. Clearly, slice 
semantics will change in GC-less environment and will require 
more restrictive operation set. No automatic slice 
concatenation at the very least.


Right. Without implementing the append function, there's a linker 
error if you try to do it:

minimal.d:29: undefined reference to `_d_arrayappendcTX'

which really isn't half bad, the line number is there too, I'll 
take it.



Another thing I'm thinking about is immutable data. String 
literals are immutable(char)[] and ok to store, so maybe any 
immutable data would be ok. I'm thinking there might be a 
newImmutable function I can make that puts the data on a special 
heap that is never free()'d. Maybe. idk, I should probably get 
back to my actual work soon anyway.


Isn't it what scope was supposed to be all about? :) 
Qualifier that prohibits leaking data outside of the current 
scope.


Maybe, but it doesn't actually work like that right now anyway.

Dunno. If something like this can be done, it will need full 
re-implementation of standard library (similar to minlibd) as 
assumption made about feature set allowed and druntime differ a 
lot.


Yeah, but manual memory stuff would be useful even if you have 
the gc so there should be some carryover possible.

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 13:21:21 UTC, Maxim Fomin wrote:


Fundamental issue here is that

const T t;

is almost useless, it is essentially immutable since you cannot 
change it and you cannot alias it. As such, it probably should 
be changed to a mutable object or an immutable one.


It's generic code. See the linked code and you'll see that this 
is not an option.



However, since const/mutable aliasing is allowed, you can do:

union U (T)
{
   const T ct;
   T mt;
}

because const doesn't mean that object would never change, you 
can mutate it through alias. From the opposite view, there is 
also no problem in reinterpeting a mutable object as const 
object (since mutables can be converted to const).


Depending on your mutable indirection situation this can work 
or may not.


Mutable indirection is actually not the problem with this 
solution, it's the casting away of const. There's no guarantee 
here that the data wasn't actually immutable when it was created.

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 13:30:09 UTC, Jakob Ovrum wrote:

However, since const/mutable aliasing is allowed, you can do:

union U (T)
{
  const T ct;
  T mt;
}

because const doesn't mean that object would never change, you 
can mutate it through alias. From the opposite view, there is 
also no problem in reinterpeting a mutable object as const 
object (since mutables can be converted to const).


Depending on your mutable indirection situation this can work 
or may not.


Mutable indirection is actually not the problem with this 
solution, it's the casting away of const. There's no guarantee 
here that the data wasn't actually immutable when it was 
created.


It is not casting away const and it has nothing to do with 
immutable, also this does not suffer from data was actually 
immutable problem.

Re: [article] Language Design Deal Breakers


On Wed, 29 May 2013 14:15:07 +0100, deadalnix deadal...@gmail.com wrote:


On Wednesday, 29 May 2013 at 12:19:54 UTC, Regan Heath wrote:
I started discussing this because people where claiming that non null  
makes the compiler more complex to implement, which is completely  
false.


That's not the argument being made by Simen.  The argument is that  
@disable this() is a feature which allows a set of features which  
include but is not limited to not-null, and is therefore a superior  
feature to have.


Do you agree?



I do agree that @disable this is useful. *BUT* the argument made is  
based on the untold assumption that both are mutually exclusive, which  
is not true.


I don't believe anyone is arguing that they are mutually exclusive, only  
that @disable is sufficient to do the job.


IMO, this then renders any specific not-null language feature  
unnecessary.  And, allows a library type to do the job.




Most people agree that you'll find 2 useful behavior : non nullable and  
nullable with obligation of handling the null case. The default behavior  
right now provide none of thoses. It behave just as if it were non  
nullable, and simply crash when they happen to be null.


Which default behaviour?  D's references/pointers?  Or the proposed  
NotNull!(T) library solution?


This behavior isn't useful. You'll find no argument except historical  
reason (which is a very valid argument BTW) to keep that. Everything  
else is backward rationalization.


If @disable is insufficient for a NotNull!(T) which does what we need it  
to do, then more features are required.  Ignoring the bugs in @disable, do  
you believe it is insufficient?  If so, can you give us some example  
usages it does not yet support/allow/provide for.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 13:35:18 UTC, Maxim Fomin wrote:
It is not casting away const and it has nothing to do with 
immutable, also this does not suffer from data was actually 
immutable problem.


The data is not initially constructed by the local function, it's 
clearly coming from somewhere else and there's no guarantee that 
it's not returning a const view of immutable data. The code is 
not limited to accepting const, of course, and exhibits the same 
problem when the function returns immutable data.


Unions are a convenience feature, it boils down to the same as a 
cast and has the same problems (actually worse because the 
conversion is not explicit).

Re: Const initialization issue, looking for solution


On Wednesday, 29 May 2013 at 13:44:15 UTC, Jakob Ovrum wrote:

On Wednesday, 29 May 2013 at 13:35:18 UTC, Maxim Fomin wrote:
It is not casting away const and it has nothing to do with 
immutable, also this does not suffer from data was actually 
immutable problem.


The data is not initially constructed by the local function, 
it's clearly coming from somewhere else and there's no 
guarantee that it's not returning a const view of immutable 
data. The code is not limited to accepting const, of course, 
and exhibits the same problem when the function returns 
immutable data.


Unions are a convenience feature, it boils down to the same as 
a cast and has the same problems (actually worse because the 
conversion is not explicit).


If you accept const object as a parameter, then yes.

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 12:41:44 UTC, Flamaros wrote:

On Wednesday, 29 May 2013 at 11:36:54 UTC, Paulo Pinto wrote:

On Wednesday, 29 May 2013 at 09:40:33 UTC, Flamaros wrote:

On Wednesday, 29 May 2013 at 08:49:24 UTC, Paulo Pinto wrote:

On Tuesday, 28 May 2013 at 21:25:05 UTC, Flamaros wrote:

Hi,

I and a friend are developing a GUI library, and now our 
script engine is ready to start a prototype (but far to be 
finished). We think to try to create a GUI editor based on 
our library.

In this way, we'll see which features are need.

My concern is about how the editor have to works, we see 
two different ways to do it :

1) Classic editor external to the user applications
a) Good :
- Lightweight (easy to deploy and test)
- No need to modify application code
- Stable due to isolation of application
- Real-time edition but limited on one view (bad to preview 
menus transitions)

b) Bad :
- Limited, plugins needed to extend editor components and 
his knowledge of application (can't predict size of unknown 
application specific items)


2) Integrated editor (launch with the user application in a 
second Window)

a) Good :
- Preview is the final result with real data
- All application components accessible to the editor 
without complex plugin system (in this way all editors 
components will be well placed in the preview)

- Full real-time edition (can preview menus transitions,...)
- User can customize the editor
b) Bad :
- Intrusive in the application code
- Force the user to port application on a desktop OS 
(Linux, Mac or Windows), not friendly if he target only 
embedded devices (can be bypassed with a remote system)

- Less stable editor?

The second solution is commonly used in the video game 
industry, but is the best choice for a larger usage?


What do you think about?


I always hold Delphi and C++ Builder as examples of a what a 
good UI editor should offer.


Currently Blend + VS are also another good examples for 
proper tooling for making good UIs.


--
Paulo


It seems Blend can directly run on top of the application. 
Are you using this feature?


What you mean by run on top ?

I use it to have a look if everything looks like and for some 
stuff I need to execute the application but it requires 
runtime information.


Blend can work with VS solutions and also invoke MSBuild, but 
if you are doing custom controls and stuff it is better to do 
certain parts from VS side, hence using both.


--
Paulo


Do blend works with C++?


Yes, in Windows 8 Apps when doing XAML with C++/CX.

After 16 years, Microsoft finally catches up with Borland's C++ 
Builder.


I don't know how it run on top but on the documentation page 
tell that it can be aware of states that are normally only on 
run-time. Maybe with a static introspection or like we propose 
with the intrusive way.


Yes, that is possible, but not for everything. Like in most UI 
toolkits, your components need to be aware of a design mode.


--
Paulo

Re: [article] Language Design Deal Breakers


On Wednesday, 29 May 2013 at 13:36:16 UTC, Regan Heath wrote:
Which default behaviour?  D's references/pointers?  Or the 
proposed NotNull!(T) library solution?




The default behavior. The one you get our of the box. So not 
NonNullable.


This behavior isn't useful. You'll find no argument except 
historical reason (which is a very valid argument BTW) to keep 
that. Everything else is backward rationalization.


If @disable is insufficient for a NotNull!(T) which does what 
we need it to do, then more features are required.  Ignoring 
the bugs in @disable, do you believe it is insufficient?  If 
so, can you give us some example usages it does not yet 
support/allow/provide for.




I don't know what you answer to, but clearly not what you are 
quoting.

Re: Need some opinions for a GUI editor


On Wednesday, 29 May 2013 at 13:52:31 UTC, Paulo Pinto wrote:



Do blend works with C++?


Yes, in Windows 8 Apps when doing XAML with C++/CX.

After 16 years, Microsoft finally catches up with Borland's C++ 
Builder.


I don't know how it run on top but on the documentation page 
tell that it can be aware of states that are normally only on 
run-time. Maybe with a static introspection or like we propose 
with the intrusive way.


Yes, that is possible, but not for everything. Like in most UI 
toolkits, your components need to be aware of a design mode.


--
Paulo


The intrusive method we think about, will allow use to get a full 
control of all items derived from our basics objects. So I 
imagine your prefer this solution?

Re: [article] Language Design Deal Breakers

2013-05-29 Thread Andrei Alexandrescu


On 5/29/13 1:56 AM, Diggory wrote:

On Wednesday, 29 May 2013 at 05:35:14 UTC, Walter Bright wrote:

On 5/28/2013 9:55 PM, Diggory wrote:

As a last resort there should be a runtime check available such as
assertNotNull(T) which does the conversion.


The idea is to put the check on assignments to NotNull, not on usage
of it.


I know, that's what my suggestion was for.

assertNotNull(T) would return a NotNull!T given a T (probably should
have explained that)


assume?

Andrei

Re: [article] Language Design Deal Breakers


On Wed, 29 May 2013 15:09:11 +0100, deadalnix deadal...@gmail.com wrote:

On Wednesday, 29 May 2013 at 13:36:16 UTC, Regan Heath wrote:
Most people agree that you'll find 2 useful behavior : non nullable  
and nullable with obligation of handling
the null case. The default behavior right now provide none of thoses.  
It behave just as if it were non

nullable, and simply crash when they happen to be null.

Which default behaviour?  D's references/pointers?  Or the proposed  
NotNull!(T) library solution?




The default behavior. The one you get our of the box. So not NonNullable.


Clearly then NonNullable or @disable is buggy.  Isn't this what Walter  
meant when he said he was going to patch the holes?


So, assuming the implementation of @disable and NotNullable are fixed to  
provide the 2 useful behaviours mentioned above, problem solved right?


This behavior isn't useful. You'll find no argument except historical  
reason (which is a very valid argument

BTW) to keep that. Everything else is backward rationalization.


If @disable is insufficient for a NotNull!(T) which does what we need  
it to do, then more features are required.  Ignoring the bugs in  
@disable, do you believe it is insufficient?  If so, can you give us  
some example usages it does not yet support/allow/provide for.




I don't know what you answer to, but clearly not what you are quoting.


I quoted it, but inserted my comment above between your 2 paras.  You then  
stripped it from your reply :P

I have re-quoted it above Most people agree...

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: [article] Language Design Deal Breakers

2013-05-29 Thread Kenji Hara

2013/5/29 Adam D. Ruppe destructiona...@gmail.com

 On Wednesday, 29 May 2013 at 04:15:52 UTC, Walter Bright wrote:

 It's not in Phobos yet:


 I did a pull request a while ago that stalled for some reason I don't
 remember now, but the struct I did needed to be a little more complex than
 yours to pass all the tests

  [snip]

I opened a new Phobos pull request as a discussion basis.
https://github.com/D-Programming-Language/phobos/pull/1321

If the discussion will spread, I'll spend my some time for that from now.

Kenji Hara

Re: [article] Language Design Deal Breakers


On Wednesday, 29 May 2013 at 14:47:31 UTC, Regan Heath wrote:
This behavior isn't useful. You'll find no argument except 
historical reason (which is a very valid argument
BTW) to keep that. Everything else is backward 
rationalization.


If @disable is insufficient for a NotNull!(T) which does what 
we need it to do, then more features are required.  Ignoring 
the bugs in @disable, do you believe it is insufficient?  If 
so, can you give us some example usages it does not yet 
support/allow/provide for.




I don't know what you answer to, but clearly not what you are 
quoting.


I quoted it, but inserted my comment above between your 2 
paras.  You then stripped it from your reply :P

I have re-quoted it above Most people agree...



No, you get that @disable this() is not sufficient from anywhere 
but from my post. This craziness is going on for pages now. I'm 
stopping now, as it isn't going anywhere.


I'm still ready to discuss point I actually raised. The fact that 
@disable this() is not sufficient to implement NonNullable isn't 
one of them.

Re: [article] Language Design Deal Breakers