I have just committed the changes necessary for (ascii) string
indexing and (ascii) string-foreach.
Currently working on UTF8 => UTF32 auto-re-encoding and
StringConcat and Slice-Support.
Completion of Slice support will also fix the interplay between
structs and arrays.
Cheers,
Stefan
On 8/11/2016 12:59 PM, Joseph Rushton Wakeling wrote:
There's a use-case that relates to some of our discussions together in another
context, about structs or classes that borrow data via ref:
The scheme does not implement borrowing. References to internal data should be
returned via 'return r
On 8/11/2016 6:38 AM, Sönke Ludwig wrote:
What would be nice to add is a behavior specification for 'scope' member
variables (lifetime considered equal or slightly shorter than parent object
lifetime). For example the `RefCountedSlice.payload` and `count` fields could be
annotated with 'scope' to
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
The first DIP has just landed into the new queue. It is a (...)
The wording is unclear in the section "Implicit Conversion of
Function Pointers and Delegates".
It says "scope can be added to parameters, but not removed."
The troub
On Wed, Aug 10, 2016 at 08:35:23PM +, Dicebot via Digitalmars-d-announce
wrote:
> The first DIP has just landed into the new queue. It is a proposal from
> language authors and thus it bypasses usual nitpicking process and proceeds
> straight to requesting community (your!) feedback.
>
> Esse
On Thursday, 11 August 2016 at 19:59:22 UTC, Joseph Rushton
Wakeling wrote:
Any chance the proposal authors could add some examples of how
scope could affect class/struct fields which borrow data by
reference (meaning the class/struct instance should not escape
the scope of the input data)?
S
On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
- At this point the question I'd personally suggest to be
evaluated is "does this proposal enable enough useful
designs?". A good check would be to try taking some of your
projects and see if having DIP1000 approved and implemented
c
This looks like the best proposal so far. Many useful ideas, and at the
first glance it looks like a big step forward. I also really like how
the useful stack allocation behavior for closures and new'ed values is
kept alive.
What would be nice to add is a behavior specification for 'scope' mem
On 8/10/2016 11:36 PM, rikki cattermole wrote:
Perfect :)
The nice thing about this scheme is it can do some things that Rust can't (and
Rust can do things that this can't). I suppose it will balance out.
