Re: [OT] Microsoft filled patent applications for scoped and immutable types
Walter Bright Wrote in message: > On 8/27/2014 12:50 PM, Idan Arye wrote: >> Aren't these the patent numbers? > > Nope. Too many digits. Tried them, the form rejected them. > Spoke too soon. A patent number has not been issued as far as I can tell. This is listed in the application database. From the USPTO FAQ: Does your database include data on pending patent applications? The database only includes data on Published Applications in accordance with the 18 month pre-grant publication rules. Pending patent applications where the applicant has elected to not publish prior to grant remain confidential. --
Re: [OT] Microsoft filled patent applications for scoped and immutable types
Walter Bright Wrote in message: > On 8/27/2014 12:50 PM, Idan Arye wrote: >> Aren't these the patent numbers? > > Nope. Too many digits. Tried them, the form rejected them. > Application number : 13/734750 Patent number: 0196008 --
Re: Case for std.experimental
"Dicebot" Wrote in message: > What keeps bothering me is this: imagine something has not passed > vote for std.experimental inclusion. That means that some changes > will happen, one more voting and it will eventually get there one > release later. > > And if has passed the vote, effectively the same stuff happens - > changes are done, staging period prolonged and we get to the very > same point. Only difference is that earlier versions of the > module don't get wider user exposure. > > Now that I see several comments here seeking for certain > stability even in std.experimental and can understand why later > exposure can be a good thing. That, however, makes me even more > convinced that "experimental" is a terrible name for that package > and we are using it purely as staging are instead. > std.purgatory
Re: Case for std.experimental
"Dicebot" Wrote in message: > On Tuesday, 29 July 2014 at 17:35:34 UTC, Andrei Alexandrescu > wrote: >> I'd just want to have a simple litmus test that prevents >> std.experimental from becoming a dumping ground of unfinished >> work. Consider: >> >> "Folks, here's std.experimental.acme. I think it's usable and >> fairly stable but I'm sure I didn't think of all possible >> issues and use cases. Documentation could be also improved." >> >> vs >> >> "Folks, here's std.experimental.acme. The entire user-facing >> API is sure to change and it doesn't pass what some deem to be >> basic acceptance terms. Try it, but you can be sure you'll need >> to overhaul all use of it when it's done." > > What keeps bothering me is this: imagine something has not passed > vote for std.experimental inclusion. That means that some changes > will happen, one more voting and it will eventually get there one > release later. > > And if has passed the vote, effectively the same stuff happens - > changes are done, staging period prolonged and we get to the very > same point. Only difference is that earlier versions of the > module don't get wider user exposure. > > Now that I see several comments here seeking for certain > stability even in std.experimental and can understand why later > exposure can be a good thing. That, however, makes me even more > convinced that "experimental" is a terrible name for that package > and we are using it purely as staging are instead. > --
