On Thu, Jul 30, 2015 at 12:43:40PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/30/2015 9:58 AM, Brad Anderson wrote:
> >If we can't have the minimal necessary module paths then I'm completely in favor of parseJSONStream over the more general parseStream. I want that "json" in there one way or another (preferably by the method which makes it optional while maintaining brevity).
> 
> I would think it unlikely to be parsing two different formats in one file.  But in any case, you can always do this:
> 
>    import std.data.json : parseJSON = parse;
> 
> Or put the import in a scope:
> 
>    void doNaughtyThingsWithJson()
>    {
>        import std.data.json;
>        ...
>        x.parse();
>    }
> 
> The latter seems to be becoming the preferred D style.

Yeah, local imports are fast becoming my preferred D coding style, because it makes code portable -- if you move a function to a new module, you don't have to untangle its import dependencies if all imports are local. It's one of those little, overlooked things about D that contribute toward making it an awesome language.


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.

On 7/30/2015 12:57 PM, H. S. Teoh via Digitalmars-d wrote:
> Yeah, local imports are fast becoming my preferred D coding style,
> because it makes code portable -- if you move a function to a new
> module, you don't have to untangle its import dependencies if all
> imports are local. It's one of those little, overlooked things about D
> that contribute toward making it an awesome language.

Funny how my preferred D style of writing code is steadily diverging from C++ style :-)

On Thu, Jul 30, 2015 at 01:26:17PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/30/2015 12:57 PM, H. S. Teoh via Digitalmars-d wrote:
> >Yeah, local imports are fast becoming my preferred D coding style, because it makes code portable -- if you move a function to a new module, you don't have to untangle its import dependencies if all imports are local. It's one of those little, overlooked things about D that contribute toward making it an awesome language.
> 
> Funny how my preferred D style of writing code is steadily diverging from C++ style :-)

One would hope so, otherwise why are we here instead of in the C++ world? ;-)


T

-- 
This is not a sentence.

is the current build is ready for production? I am getting error:

source\stdx\data\json\value.d(81): Error: safe function 'stdx.data.json.value.JSONValue.this' cannot call system function 'std.variant.VariantN!(12u, typeof(null), bool, double, long, BigInt, string, JSONValue[], JSONValue[string]).VariantN.__ctor!(typeof(null)).this'

Am 31.07.2015 um 10:13 schrieb Suliman:
> is the current build is ready for production? I am getting error:
>
> source\stdx\data\json\value.d(81): Error: safe function
> 'stdx.data.json.value.JSONValue.this' cannot call system function
> 'std.variant.VariantN!(12u, typeof(null), bool, double, long, BigInt,
> string, JSONValue[],
> JSONValue[string]).VariantN.__ctor!(typeof(null)).this'

2.068 "fixed" possible safety issues with VariantN by marking the interface @system instead of @trusted. Unfortunately that broke any @safe code using Variant/Algebraic.

On Friday, 31 July 2015 at 12:16:02 UTC, Sönke Ludwig wrote:
> Am 31.07.2015 um 10:13 schrieb Suliman:
>> is the current build is ready for production? I am getting error:
>>
>> source\stdx\data\json\value.d(81): Error: safe function
>> 'stdx.data.json.value.JSONValue.this' cannot call system function
>> 'std.variant.VariantN!(12u, typeof(null), bool, double, long, BigInt,
>> string, JSONValue[],
>> JSONValue[string]).VariantN.__ctor!(typeof(null)).this'
>
> 2.068 "fixed" possible safety issues with VariantN by marking the interface @system instead of @trusted. Unfortunately that broke any @safe code using Variant/Algebraic.

Wat revision are usable? I checked some and all have issue like:

source\App.d(5,34): Error: template stdx.data.json.parser.parseJSONValue cannot
deduce function from argument types !()(string), candidates are:
source\stdx\data\json\parser.d(105,11):        stdx.data.json.parser.parseJSONVa
lue(LexOptions options = LexOptions.init, Input)(ref Input input, string filenam
e = "") if (isStringInputRange!Input || isIntegralInputRange!Input)

Am 31.07.2015 um 22:15 schrieb Suliman:
> On Friday, 31 July 2015 at 12:16:02 UTC, Sönke Ludwig wrote:
>> Am 31.07.2015 um 10:13 schrieb Suliman:
>>> is the current build is ready for production? I am getting error:
>>>
>>> source\stdx\data\json\value.d(81): Error: safe function
>>> 'stdx.data.json.value.JSONValue.this' cannot call system function
>>> 'std.variant.VariantN!(12u, typeof(null), bool, double, long, BigInt,
>>> string, JSONValue[],
>>> JSONValue[string]).VariantN.__ctor!(typeof(null)).this'
>>
>> 2.068 "fixed" possible safety issues with VariantN by marking the
>> interface @system instead of @trusted. Unfortunately that broke any
>> @safe code using Variant/Algebraic.
>
> Wat revision are usable? I checked some and all have issue like:
>
> source\App.d(5,34): Error: template stdx.data.json.parser.parseJSONValue
> cannot
> deduce function from argument types !()(string), candidates are:
> source\stdx\data\json\parser.d(105,11): stdx.data.json.parser.parseJSONVa
> lue(LexOptions options = LexOptions.init, Input)(ref Input input, string
> filenam
> e = "") if (isStringInputRange!Input || isIntegralInputRange!Input)

parseJSONValue takes a reference to an input range, so that it can consume the input and leave any trailing text after the JSON value in the range. For just converting a string to a JSONValue, use toJSONValue instead.

I'll make this more clear in the documentation.

> parseJSONValue takes a reference to an input range, so that it can consume the input and leave any trailing text after the JSON value in the range. For just converting a string to a JSONValue, use toJSONValue instead.
>
> I'll make this more clear in the documentation.

Yes please, because it's hard to understand difference. Maybe it's possible to simplify it more?

Also I get trouble with extracting value:

response = toJSONValue(res.bodyReader.readAllUTF8());	

writeln(to!int(response["code"]));

C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(295,24): Error: template std.c
onv.toImpl cannot deduce function from argument types !(int)(VariantN!20u), cand
idates are:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(361,3):        std.conv.toImpl
(T, S)(S value) if (isImplicitlyConvertible!(S, T) && !isEnumStrToStr!(S, T) &&
!isNullToStr!(S, T))


If I am doing simple:
writeln(response["code"]);

Code produce right result (for example 200)

What value consist in key "code"? It's look like not simple "200". How I can convert it to string or int?

Look like it's Variant type. So I tried to use method get! do extract value from it
writeln(get!(response["code"]));

But I get error: Error: variable response cannot be read at compile time

Am 01.08.2015 um 16:15 schrieb Suliman:
> Look like it's Variant type. So I tried to use method get! do extract
> value from it
> writeln(get!(response["code"]));
>
> But I get error: Error: variable response cannot be read at compile time

The correct syntax is: response["code"].get!int